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SYSTEMS AND METHODS FOR FACILITATING COMMERCIAL 
TRANSACTIONS BETWEEN PARTIES RESIDING AT REMOTE LOCATIONS 

FIELD OF THE INVENTION 

5 The present invention generally relates to online financial transactions and, 

more particularly, to the facilitation of commercial transactions between parties residing 
at remote locations, as in the case of transactions between users of a distributed 
computer network. 

10 BACKGROUND OF THE INVENTION 

The advent of the Internet has rendered electronic commerce (e-commerce) 
one of the fastest growing segments of the global economy. The growth of e- 
commerce is due, in part, to the ever-expanding array of goods and services available 
to online users and the ease with which Internet access can be obtained. Each year, 

15 as general use of, and familiarity with, the Internet becomes more pervasive, the 
number of commercial transactions facilitated by the Internet is expected to escalate 
dramatically. The Internet is easily accessible, and the products and services available 
to users of the network are virtually limitless. In addition to allowing large merchants to 
sell products and services, the Internet offers a platform through which geographically 

20 remote small merchants and individuals can easily conduct a variety of transactions 
with each other. Thus, the Internet represents an opportunity for the exercise of 
unparalleled consumer purchasing power. 

However, a number of hurdles impedes the typical Internet user from engaging 
in a variety of online transactions and, therefore, from effectively leveraging this 

25 purchasing power. As the number and scope of transactional opportunities available 
to Internet users expand, individual users seeking to exploit these opportunities are 
squarely confronted with the significant challenge of transferring and receiving 
monetary value online, regardless of whether the transfer and/or receipt of monetary 
value culminates in an online sales transaction or whether it effects a simple funds 

30 transfer between individual users. While the Internet has become an extraordinarily 
efficient mechanism for the dissemination of information, the development of effective, 
secure means for engaging in online transactions for value has proved problematic 
and has been a significant factor in slowing the acceptance and growth of e- 
comm rce. 
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Generally, methods of transferring and receiving funds for onlin transactions 
can be separated into two broad categori s: onlin and off-line. Online m thods of 
transferring funds typically include transactions involving ither the transmission of 
credit card information or th us of some form of digital cash. Howev r, many 
5 individual Internet users are acutely aware that the transmission of credit card numbers 
over the Internet carries the risk of theft from unscrupulous computer hackers and 
thieves who have the ability to tap into servers connected to the Internet Since credit 
card numbers typically comprise sixteen-digit numbers having a publicly known 
pattern, once a computer hacker has accessed an appropriate server, the hacker can 

10 simply search the server for messages containing numbers having a recognized 
pattern and enjoy a fair degree of confidence that the results of such a search will yield 
messages that likely correspond to valid credit cards. Off-line methods are usually 
safer in this regard, as they may require that a check or some other cash equivalent, 
such as a money order, be sent through the mail. Nevertheless, this latter approach is 

15 generally cumbersome, time consuming, and commonly perceived as troublesome to 
the average Internet user. Moreover, none of these methods, either online or off-line, 
sufficiently addresses the logistics involved in satisfactorily coordinating both the 
transfer of monetary value from a first user to a second user and the transfer of goods, 
services, or other value from the second user to the first user. 

20 Another hurdle that often impedes widespread acceptance of commercial 

transactions between individual Internet users is that, since the Internet facilitates 
remote person-to-person communication, most online transactions suffer from a 
tenuous connection between the parties to the transaction. For example, unlike the v 
experience provided by conventional 'brick and mortar* stores, in the case of a typical pr 

25 online transaction involving the purchase of goods, online purchasers generally do not 
interact personally with sellers and often do not receive the same level of customer 
service due to the nature of the seller involved in the transaction, as well as the 
character of Internet communications. Although purchasers and sellers occasionally 
can communicate effectively either online or by telephone, purchasers often cannot 

30 examine the quality of the goods that they are interested in purchasing. Frequently, an 
individual purchaser's inability to inspect the goods prior to remitting payment and/or 
the purchaser's lack of knowledge of the seller's integrity, in conjunction with other 
factors, creates sufficient apprehension in a purchaser's mind to derail an intended 
online purchase. Moreover, even if an individual purchaser overcomes an initial 
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h sitancy and d tides to engag in a onlin transaction with an individual seller, the 
nature of th transaction is such that th purchaser generally has little recourse in th 
vent that the seller fails to deliv r th goods or services as promised or that the goods 
or services are damaged or otherwise misrepresented. Conv rsely, th seller also has 
5 little recourse should the purchaser ultimately decide to abandon the transaction. 

In the context of commercial transactions conducted between individual Internet 
users, an additional shortcoming of conventional payment schemes is that there are 
few ways for an individual purchaser to transfer monetary value to an individual seller, 
with the exception trf cash, such that the seller may use the value transferred without 

10 first processing the transfer instrument by, for example, depositing the instrument with 
a bank or converting it into cash. In other words, the recipient of a check or other 
negotiable instrument must use a financial institution to mediate the conversion of the 
transferred value into value that the recipient can use in its own behalf. Furthermore, 
using conventional means for transferring currency between individuals, a seller may 

15 not receive financial tender until two to four weeks after performance of a service or 
shipment of the goods to the individual purchaser. Moreover, since a seller frequently 
has inventory costs associated with the particular goods offered for sale, this can result 
in the loss of valuable interest, pending the arrival of a payment through the mail 
and/or sufficient time for a bank deposit of that payment to clear the seller's bank 

20 account 

Furthermore, in the case of an online seller who is not a large merchant and 
who generally is not capable of accepting credit card payments, the ability to engage in 
a particular transaction with another Internet user may necessitate that the seller enter 
into an agreement with a credit card issuer to enable the seller to receive monetary ^ 

25 value from the other Internet user. Not only are such agreements time consuming and 
costly, but conducting a financial transaction in accordance with such an agreement 
often requires the seller to communicate confidential information, such as credit card 
numbers, to third parties, such as credit card issuers, thereby risking the security of the 
confidential information. Although alternative payment schemes, such as digital 

30 money systems (e.g., DigiCash, e-Cash, etc.) are readily envisioned, most are still in 
the early stages of development and no standards regarding their use have been 
established as of yet 

Significantly, the foregoing factors frequently adversely impact an individual 
user's willingness to engage in online commercial transactions at all. Thus, the voium 
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of conventional onlin and otMine transactions tot xcnangmg monetary vaiu is 
reduced. These losses may be du either to the individual seller's inability to process 
credit card transactions or to the individual purchaser's appreh nsion regarding 
acceptance of the risks associated with remitting online payments. Consequ ntly, 
5 there is a need for systems and methods which enable remote individuals, such as 
Internet users, to transfer monetary value in exchange for goods, services, or other 
value in a secure manner. There is also a need for systems and methods which 
enable remote individuals to receive monetary value from each other and to utilize the 
value represented by the funds transfer immediately. There is also a need for. systems 

10 and methods which enable individuals who do not typically process credit card 
transactions to receive monetary value from other individuals without being required to 
communicate confidential information to a third party and possibly risking a breach in 
the security of such information. There is an additional need for systems and methods 
which permit an individual seller to receive pre-authentication or pre-authorization of an 

15 individual purchaser's ability to transfer sufficient funds to complete a commercial 
transaction. There is also a need for systems and methods which reduce the risks 
associated with commercial transactions between remote individuals. Finally, there is 
also a need for systems and methods which provide dispute resolution mechanisms to 
remote individuals engaging in commercial or financial transactions conducted, for 

20 example, over a distributed computer network. 

SUMMARY OF THE INVENTION 

The present invention facilitates commercial transactions involving the . 
exchange of monetary value for goods, services, or other value between remote ~s 

25 individuals, such as users of a distributed computer network or Internet users. The 
present invention provides remote sellers with an irrevocable means of receiving funds 
from a remote purchaser; means for improving purchaser willingness to transact with 
an unknown party, transaction tracking; and rapid funds availability. The present 
invention also provides remote purchasers with means for making a secure, 

30 confidential transfer of funds; means for immediate initiation of shipment by a seller; 
means for releasing funds to a seller only after approval of the goods, services, or 
other value received from the seller; means for demonstrating proof of payment; and 
means for having some level of recourse against a remote seller. 
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More particularly, th invention fadlitat s commercial transactions by suitably 
coordinating the transfer of financial t nd r from a financial account associated with a 
first party t a financial account associated with a second party in exchang for th 
transfer of goods, services, or other valu from a second party to a first party. Th 
5 system includes registering a first party with a transaction mechanism; registering a 
second party with the transaction mechanism; receiving, from at least one of a first 
party and a second party, a request to debit a financial account associated with the 
first party to effectuate a transaction between the first party and the second party; 
receiving, fronrv at least one of a first party and a second party, transaction information 

10 r lating to the transaction; determining whether the transaction is acceptable, wherein 
the determination of acceptability is based upon at least one of the transaction 
information and the request to debit the financial account of the first party; debiting 
funds from the financial account of the first party, and holding the corresponding funds 
in an escrow account until an escrow event has transpired; releasing the funds from 

1 5 the escrow account and disbursing the funds to a financial account associated with the 
second party; and crediting funds to the financial account of the second party. 

Registration of either a first party or a second party may include providing the 
transaction mechanism with a suitable financial account identifier, such as a card 
number, demand deposit account (DDA) number, or any suitable part of the number, to 

20 identify the financial account of either the first party or the second party. Moreover, 
transaction information received from at least one of the first party and the second 
party can include a financial account identifier associated with the financial account of^ 
the first party. Furthermore, a request for a value-added service can be received from* 
the first party and/or "the second party, and receiving the request for a value-added 

25 service can further include receiving a request for a value-added service such as 
insurance, dispute resolution, postal tracking, and/or the like. Additionally, determining 
whether the transaction is acceptable can further include a credit risk analysis and/or a 
fraud detection analysis. 

30 BRIEF DESCRIPTION OF THE DRAWINGS 

Additional aspects of the present invention will become evident upon reviewing 
the non-limiting embodiments described in the specification and the claims taken in 
conjunction with the accompanying figures, wherein like numerals designate like 
elem nts, and: 
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FIG. 1 is an exemplary schematic diagram of a pnor art syst m tor conducting a 
commercial transaction between parties who are remot ly located from on anoth r t 

FIGS. 2-4 are schematic block diagrams illustrating xemplary transaction 
syst ms in accordance with various aspects of the present invention; 
5 FIG. 5 is a schematic block diagram of an exemplary transaction mechanism in 

accordance with the present invention; 

FIG. 6 is a flowchart representing an exemplary commercial transaction in 
accordance with the present invention; 

FIG, ~7 is a flowchart of an exemplary transactional mechanism in accordance _. 

1 0 with the present invention; 

FIG. 8 is a schematic block diagram of the process flow for an exemplary 
transaction system in accordance with the present invention; 

FIG. 9 is a schematic relational diagram associating exemplary actors and 
exemplary transaction processes in accordance with the present invention; 
15 FIG. 10 is an exemplary interface for facilitating user registration with the 

transaction mechanism; 

FIG. 11 is an exemplary interface for facilitating user login with the transaction 
mechanism; 

FIG. 12 is an exemplary interface for facilitating transaction initiation; 
20 FIG. 1 3 is a flowchart representing an exemplary seller-initiated transaction; 

FIG. 14 is an exemplary interface for facilitating the entry of transaction - 
information by a user; <*r 

FIG. 15 is an exemplary interface depicting an exemplary transaction invoice; 

FIG. 16 is^an exemplary interface for informing a user of the cancellation of a 
25 transaction; 

FIG. 17 is a flowchart representing an exemplary purchaser transaction 
confirmation; 

FIG. 18 is an exemplary interface for facilitating the entry of transaction 
information by a user; 

30 FIGS. 19A and 19B represent an exemplary interface depicting an exemplary 

transaction invoice; 

FIG. 20 is an exemplary interface for informing a user of the non-acceptance of 
a transaction; 
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FIG. 21 illustrates an xemplary transaction mechanism in accordance with 
various aspects of th present invention; and 

FIG. 22 represents an exemplary syst m for processing th submission of 
financial transactions. 

5 

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 

The present invention may be described herein in terms of functional block 
components, screen shots, optional selections, and various processing steps. It 
should be appreciated that ^ucb4unctional blocks may be realized by any. number of 

10 hardware and/or software components configured to perform the specified functions. 
For example, the present invention may employ various integrated circuit components, 
e.g., memory elements, processing elements, logic elements, look-up tables, and the 
like, which may carry out a variety of functions under the control of one or more 
microprocessors or other control devices. Similarly, the software elements of the 

15 present invention may be implemented with any programming or scripting language 
such as C, C++, Java, COBOL, assembler, PERL, or the like, with the various 
algorithms being implemented with any combination of data structures, objects, 
processes, routines or other programming elements. Further, it should be noted that 
the present invention may employ any number of conventional techniques for data 

20 transmission, signaling, data processing, network control, and the like. For a basic 

introduction to cryptography, please review a text written by Bruce Schneider which is * 
entitled "Applied Cryptography: Protocols, Algorithms, And Source Code In C," 
published by John Wiley & Sons (second edition, 1996), which is hereby incorporated - > 
by reference. ^ 

25 It should be appreciated that the particular implementations shown and 

described herein are illustrative of the invention and its best mode and are not 
intended to otherwise limit the scope of the present invention in any way. Indeed, for 
the sake of brevity, conventional data networking, application development, and other 
functional aspects of the systems (and components of the individual operating 

30 components of the systems) may not be described in detail herein. Furthermore, the 
connecting lines shown in the various figures contained herein are intended to 
represent exemplary functional relationships and/or physical couplings between the 
various elements. It should be noted that many alternative or additional functional 
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relationships or physical connections may be present in a practical electronic 
transaction system. 

It will be appreciated that many applications of th pres nt inv nti n could be 
f rmulated. One skilled in th art will appreciate that the n twork may include any 
5 system for exchanging data or transacting business, such as the Internet, an intranet, 
an extranet, WAN, LAN, satellite communications, and/or the like. The users may 
interact with the system via any input device such as a keyboard, mouse, kiosk, 
personal digital assistant, handheld computer (e.g., Palm Pilot®), cellular phone, 
and/or the like. Similarly, the invention could be used in conjunction with any type of 

10 personal computer, network computer, workstation, minicomputer, mainframe, or the 
like running any operating system such as any version of Windows, Windows NT, 
Windows 2000, Windows 98, Windows 95, MacOS, OS/2, BeOS, Linux, UNIX, or the 
like. Moreover, although the invention is frequently described herein as being 
implemented with TCP/IP communications protocols, it will be readily understood that 

15 the invention could also be implemented using IPX, Appletalk, IP-6, NetBIOS, OS!, or 
any number of existing or future protocols. Moreover, the system contemplates the 
use, sale, or distribution of any goods, services, or information over any network 
having similar functionality described herein. 

The customer and merchant may represent individual people, entities, or 

20 businesses. Although labeled as a "bank," the bank may represent other types of card 
issuing institutions, such as credit card companies, card sponsoring companies, or < 
third party issuers under contract with financial institutions. It is further noted that other 
participants may be involved in some phases of the transaction, such as an 4 
intermediary settlement institution, but these participants are not shown. 

25 Each participant is equipped with a computing system to facilitate online 

commerce transactions. The customer has a computing unit in the form of a personal 
computer, although other types of computing units may be used, including laptops, 
notebooks, hand held computers, seMop boxes, and the like. The merchant has a 
computing unit implemented in the form of a computer-server, although other 

30 implementations are possible. The bank has a computing center shown as a main 
frame computer. However, the bank computing center may be implemented in other 
forms, such as a mini-computer, a PC server, a network set of computers, and/or the 
like. 
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Th computing units are connected with each other via a data communication 
network. Th network is a public network and assumed to be insecure and open to 
eavesdroppers. In the illustrated impl mentation, the network is mbodied as th 
internet In this context, th computers may or may not be conn cted to the Int met at 
5 all times. For instance, the customer computer may employ a modem to occasionally 
connect to the Internet, whereas the bank computing center might maintain a 
permanent connection to the Internet. It is noted that the network may be implemented 
as other types of networks, such as an interactive television (17V) network. 
- — - -The-mers*ant ^»raptf bank computer are interconnected via. a_ 

10 second network, referred to as a payment network. The payment network represents 
existing proprietary networks that presently accommodate transactions for credit cards, 
debit cards, and other types of financial/banking cards. The payment network is a 
closed network that is assumed to be secure from eavesdroppers. Examples of the 
payment network include the American Express®, VisaNet®, and the Veriphone® 

15 networks. 

The electronic commerce system is implemented at the customer and issuing 
bank. In an exemplary implementation, the electronic commerce system is 
implemented as computer software modules loaded onto the customer computer and 
the banking computing center. The merchant computer does not necessarily require 

20 any additional software to participate in the online commerce transactions supported 
by the online commerce system. 

A customer account number generally is between fifteen and nineteen digits - 
long and is frequently a sixteervdigit credit card number. Credit card numbers comply ^ 
with a standardized format, usually having four spaced sets of numbers, as 

25 represented by the number "0000 0000 0000 0000*. The first five to seven digits are 
reserved for processing purposes and identify the issuing bank, card type and etc. 
The last, sixteenth digit is used as a sum check for the sixteen-digit number. The 
intermediary eight-to-ten digits are used to uniquely identify the customer. 

As will be appreciated by one of ordinary skill in the art, the present invention 

30 may be embodied as a method, a data processing system, a device for data 
processing, and/or a computer program product Accordingly, the present invention 
may take the form of an entirely software embodiment, an entirely hardware 
embodiment, or an embodiment combining aspects of both software and hardware. 
Furthermore, the present invention may take the form of a computer program product 
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on a computernreadabl storage medium having comput r-readabl program code 
means embodied in the storage medium. Any suitabl computer-readable storage 
medium may be utilized, including hard disks, CD-ROM, optical storage devices, 
magnetic storage devices, and/or th like. 
5 The present invention is described below with reference to block diagrams and 

flowchart illustrations of methods, apparatus (e.g., systems), and computer program 
products according to various aspects of the invention. It will be understood that each 
functional block of the block diagrams and the flowchart illustrations, and combinations 
of functional blocks in the block diagrams and flowchart illustrations, respectively,, ran 

10 be implemented by computer program instructions. These computer program 
instructions may be loaded onto a general purpose computer, special purpose 
computer, or other programmable data processing apparatus to produce a machine, 
such that the instructions which execute on the computer or other programmable data 
processing apparatus create means for implementing the functions specified in the 

1 5 flowchart block or blocks. 

These computer program instructions may also be stored in a computer- 
readable memory that can direct a computer or other programmable data processing 
apparatus to function in a particular manner, such that the instructions stored in the 
computer-readable memory produce an article of manufacture including instruction 

20 means which implement the function specified in the flowchart block or blocks. The 
computer program instructions may also be loaded onto a computer or other 
programmable data processing apparatus to cause a series of operational steps to be 
performed on the computer or other programmable apparatus to produce a computer- 
implemented process 5 ' such^that the instructions which execute on the computer or 

25 other programmable apparatus provide steps for implementing the functions specified 
in the flowchart block or blocks. 

Accordingly, functional blocks of the block diagrams and flowchart illustrations 
support combinations of means for performing the specified functions, combinations of 
steps for performing the specified functions, and program instruction means for 

30 performing the specified functions. It will also be understood that each functional block 
of the block diagrams and flowchart illustrations, and combinations of functional blocks 
in the block diagrams and flowchart illustrations, can be implemented by either special 
purpose hardware-based computer systems which perform the specified functions or 
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st ps t or suitable combinations of special purpos hardware and computer 
instructions. 

As background, FIG. 1 illustrates an exemplary prior art m thod for conducting 
an onlin commercial transaction between individual users of a distributed computer 
5 network, such as the Internet Initially, individual users contact each other over th 
network and agree to the terms of a transaction (step 1 ). If the particular transaction is 
a sales transaction involving goods, for example, the purchaser mails a check, money 
order, or other suitable negotiable instrument to the seller (step 2). Once the seller 
receives the negotiable instrument, the seller-deposits it .with an appropriate financial 

10 institution, such as a bank (step 3). When the bank clears the check through the 
s ller's account the seller is given access to the funds (step 4). The seller then ships 
the goods to the purchaser (step 5), and the purchaser receives the goods (step 6). 
Generally, this process involves an elapsed time of approximately two to three weeks 
before the seller receives "good funds" for the transaction, and three to four weeks until 

15 the purchaser receives the goods. Moreover, this process may include the purchaser 
disclosing his/her name and address to the seller to effect the transaction, and the 
purchaser has little or no recourse if either the seller fails to deliver the goods as 
promised or the goods are damaged or otherwise misrepresented. 

The present invention comprises systems, methods, and computer program 

20 products for facilitating commercial transactions between remote individuals, wherein 
the transactions often include person-to-person transfers of funds. In a preferred 
aspect the present invention facilitates commercial transactions comprising sales 
transactions conducted between remote individuals, such as transactions between 
users of a distributed ^mpute&network. One skilled in the art will appreciate that the 

25 phrase "person-to-person transfers of funds", as used herein, includes, for example, 
transfers from a financial account of a first party, which may be an individual or an 
entity, to the financial account of a second party, which may be an individual or an 
ntity. One skilled in the art further will appreciate that a 'financial account 0 or 
"account 9 can include a card account, a demand deposit account, a credit line, a 

30 money market account, a digital cash account, and/or any other financial account. 
Thus, a person-to-person transfer of funds can include card to card transfers of 
monetary value, card to demand deposit account (DDA) funds transfers, DDA to card 
transfers, card to credit line transfers, credit line to card transfers, and/or the like. 
Moreover, funds transfers in accordance with the present invention can be between 
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financial accounts held with ither the sam financial institution or different financial 
institutions. A "financial institution", as will be appreciated by on of ordinary skill in th 
art, can includ any suitabl third party, such as a bank, a card issuer, a lender, a 
credit union, and/or the like. 
5 Further, as one skilled in the art will appreciate, a "transaction card* or "card", as 
used herein, includes any device, code, or suitable financial instrument representing 
an account with a financial institution, such as a bank, a card issuer, and/or the like, 
wherein the device, code, or other suitable financial instrument has a credit line or 
balance associated with IV and^wherein the credit line or balance is in a. form oLa 

10 financial tender having discrete units, such as currency. Moreover, a "transaction card" 
or "card", as used herein, includes any device, code, or financial instrument suitably 
configured to allow the cardholder to interact or communicate with the system, such as, 
for example, a charge card, credit card, debit card, prepaid card, telephone card, smart 
card, magnetic stripe card, bar code card, authorization/access code, personal 

15 identification number (PIN), Internet code, other identification code, and/or the like. 
Additionally, a "cardholder* or "cardmember* includes any person or entity which uses 
a transaction card and participates in the present system and may include a person 
who is simply in possession of a financial account identifier, such as an authorization 
or account code. Similarly, a "demand deposit account" may include any suitable 

20 financial account, such as a bank account (e.g., checking, savings, money market, 
credit line, etc.) or other financial account maintained by a third party (such as a 
suitably insured financial institution), such account preferably having a balance of ~* 
substantially the same financial tender as the card. * 
Communicatiombetween the parties to the transaction and the system of the 

25 present invention is accomplished through any suitable communication means, such 
as, for example, a telephone network, Intranet, Internet, point of interaction device 
(point of sale device, personal digital assistant, cellular phone, kiosk, etc.), online 
communications, off-line communications, wireless communications, and/or the like. 
One skilled in the art will also appreciate that, for security reasons, any databases, 

30 systems, or components of the present invention may consist of any combination of 
databases or components at a single location or at multiple locations, wherein each 
database or system includes any of various suitable security features, such as 
firewalls, access codes, encryption, de-encryption, compression, decompression, 
and/or th like. 
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While a person-to-person transfer may genetically be described as a transfer 
from the financial account of a first party to a financial account of a second party, for 
convent nee and purposes of brevity and consistency, the pres nt disclosure generally 
refers to the first party as the purchaser and the second party as the s Her. However, 
5 it will be recognized by those of ordinary skill in th art that th seller need not provide 
goods or services to the purchaser in exchange for the transfer of funds. While this 
often may be the case, the present disclosure is not so limited and includes 
transactions which may be gratuitous in nature, whereby the purchaser transfers funds 
from their financial account to the. financial account of the seller without the seller. 

1 0 providing any goods, services, or other value in exchange. 

In accordance with an aspect of the present invention, a person-to- person 
funds transfer may be facilitated by any suitable financial institution, such as a card 
issuer like American Express® Company for example, which suitably provides credit 
risk analysis and fraud risk analysis in essentially real-time, unlike other card-based 

15 fund transfer schemes which rely on third parties to facilitate such services. Utilization 
of third-party credit risk and fraud risk analyses, such as used in conventional funds 
transfer schemes, not only may increase the amount of time to process the funds 
transfer, but also may jeopardize the security of confidential information associated 
with the transaction due to the typical need for multiple transmissions of the relevant 

20 information. Furthermore, by reducing the participants in the transaction and by 
enabling the card issuer to facilitate the funds transfer, certain transaction fees and/or 
costs may be reduced or avoided entirely because the card issuer is positioned to ^ 
profit from the increased card use, rather than simply profiting from the fees associated ^ 
with the manner in whicfjjhe card is used by individual purchasers. 

25 In accordance with an aspect of the present invention, FIG. 2 is a diagram 

illustrating an exemplary transaction system 200. The transaction system 200 
comprises a transaction mechanism or server 202 which facilitates and controls 
commercial transactions between a purchaser 204 and a seller 206. In order to 
complete the funds transfer from the financial account of the purchaser 204 to the 

30 financial account of the seller 206, the transaction mechanism 202 communicates with 
at least one of a seller's financial institution 208, which comprises a suitable financial 
account associated with the seller 206, and a purchaser's financial institution 210, 
which comprises a suitable financial account associated with the purchaser 204. In the 
case where the seller's financial account comprises a demand deposit account, for 
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exampl , the s Iter's account can include, for example, a bank account, such as a 
savings, checking, or mon y market account associated with the seller 206. In an 
ex mplary mbodiment, the communication link betwe n th transaction m chanism 
202 and th seller's financial institution 208 can compris a suitable connection to an 
5 automated clearinghouse (ACH) for facilitating bank checking account transfers, as is 
well-known to those in the industry. 

In an exemplary embodiment, the purchaser's financial institution 210 may 
comprise the transaction mechanism 202. In another exemplary embodiment, 
transaction mechanism 202 -is maintained by an independent third party, such as an 

10 intermediary 314, as described more fully below with reference to FIG. 3. The 
communication links between and among the transaction mechanism 202, purchaser 
204, seller 206, seller's financial institution 208, and purchaser's financial institution 
210 can be implemented through one or more communications networks, such as a 
private extranet, a public Internet, and/or a third party extranet, though it will be 

15 recognized by those skilled in the art that other networks such as a public switch 
telephone network (PSTN) likewise may be utilized. Moreover, although the present 
invention may be suitably implemented with TCP/IP protocols, it will be readily 
appreciated that the invention also can be implemented using IPX, Appletalk, IP-6, 
NetBIOS, OSI, or any number of other protocols either currently known or hereafter 

20 devised. Further, in another exemplary embodiment, purchaser 204 and seller 206 are 
implemented by any suitable type of personal computer, point of interaction device, 
network computer, workstation, minicomputer, mainframe, and/or the like, which 
implementation preferably includes a suitable browser application, such as a World 
Wide Web (Web) browser; preferably having suitable encryption capability. 

25 In accordance with the present invention, it is preferred that either one or both of 

the purchaser 204 and seller 206 pre-register with the transaction mechanism 202. 
However, as those skilled in the art will appreciate, a specific registration of the 
purchaser 204 and/or the seller 206 is not required and registration may take place at 
any suitable time, including at the time of the transaction. During purchaser 

30 registration, the purchaser 204 preferably provides suitable financial account 
information, such as card information for example, and suitable purchaser identification 
information. In an exemplary embodiment, the purchaser identification and/or account 
information includes any suitable information related to the purchaser and/or the 
account, such as any one or more of the following: nam , address, demographic 
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information, social security number, telephon numDer, account number, account 
expiration date, personal identification number associated with th account, date of 
birth, mother's maiden nam , spending habit information, billing history information, 
credit history information, and/or any additional information which might identify the 
5 purchaser and the purchaser's financial account The purchaser identification 
information can be used for subsequent purchaser authentication. During seller 
registration, the seller 206 preferably provides suitable financial account information 
and suitable identification information relating to an account, such as an appropriate 
card or demand deposit account for example r ~at the sellers-financial institution 18 

10 The seller's identification information can be used for subsequent authentication. In an 
exemplary embodiment, one or both of the purchaser 204 and seller 206 are 
cardmembers or cardholders of the card issuer which is providing the transaction 
mechanism 202, thereby expediting and streamlining the registration process and, in 
another exemplary embodiment, subsequent authentication and credit/fraud analysis 

1 5 processes performed by the transaction mechanism 202. 

As illustrated in FIG. 2, a transaction 212 may be initiated by one of either the 
purchaser 204 or the seller 206. The transaction 212, which is illustrated in phantom 
lines in order to represent that it is optional, may comprise the exchange of goods, 
services, or other value from the seller 206 to the purchaser 204 in exchange for a 

20 transfer of funds from the purchaser's financial account at the purchaser's financial 
institution 210 to the seller's financial account at seller's financial institution 208. 
However, it should be appreciated that transaction 212 need not comprise an v 
xchange of goods and/or services, but rather, may comprise a gratuitous transfer of 
funds from a purchaser 204 to a seller 206. By way of example, the purchaser 204 

25 may be purchasing goods from the seller 206 which goods were identified through a 
classified ad, an Internet posting, an Internet auction, and/or the like, or, alternatively, 
the purchaser 204 may be transferring funds to the seller 206 for philanthropic, 
charitable, or other gift-giving purposes. Thus, depending upon the nature of the 
transaction 212, one of either the purchaser 204 or the seller 206 will initiate the 

30 transfer of funds by suitably providing to the transaction mechanism 202 transaction 
information. The transaction information may include identification information 
regarding one or both of the purchaser 204 and the seller 206 as well as the terms of 
the transaction, which can include suitable account information, the date arid time of 
th transaction, the amount of th funds transfer, a description of th goods, services, 



15 



WO 01/33522 



PCT/US00/30483 



or other valu , any scrow t rms (such as a suitable escrow release vent), and/or tne 
like. In addition, requests for value-add d services, such as insurance, dispute 
r solution, postal tracking, and/or the like may be mad by on or both of th 
purchaser 204 and/or th seller 206. 
5 The transaction mechanism 202 then suitably authenticates the seller 206 
and/or the purchaser 204 to ensure that they are the appropriate owners of their 
respective accounts. In an exemplary embodiment, the transaction mechanism 202 is 
provided by the purchaser's financial institution 210, such as the card issuer of a 
— purchaser's card for example, which financial institution is able to perform suitable .risk-- 

10 management functions, such as suitable credit risk and/or fraud risk analyses for 
example. The ability of the transaction mechanism 202, through a suitable financial 
institution which preferably maintains and operates the transaction mechanism 202, to 
perform credit risk and fraud risk analyses is particularly advantageous, since 
p rformance of these services by a third party not only delays the transaction process 

15 but presents an additional security risk when transmitting and processing confidential 
or transaction-sensitive information to and from the third party. Moreover, when the 
transaction mechanism 202 is provided by the purchaser's financial institution 210, 
such as a card issuer, information such as historical transactional records, account 
records, and/or the like easily can be reviewed to determine whether a credit or fraud 

20 risk exists. 

In another exemplary embodiment, the transaction mechanism 202 suitably 
determines whether the purchaser's financial account has a sufficient balance to - 
nable the funds transfer identified in the transaction information. If the purchaser 204 ^ 
has sufficient funds availaKe in the financial account, and suitable risk management 
25 and authentication processes do not result in a negative determination, the transaction 
is deemed acceptable. The transaction mechanism 202 then executes the transaction 
by debiting the purchaser's financial account and crediting a suitable escrow account 
maintained by the transaction mechanism 202. The funds debited from the 
purchaser's financial account preferably remain in the escrow account for some 
30 predefined period of time. The predefined period of time may be based upon the 
occurrence of a suitably defined escrow release event, such as any of the following 
vents: receipt by the purchaser of the goods, services, or other value; the lapse of a 
predetermined period of time within which the purchaser may evaluate the goods, 
services, or other value and either accept or refuse delivery; and/or any other suitabl , 
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predefined event. Preferably, the transaction mechanism 202 withholds th funds from 
the seller's financial account and suitably maintains th funds in the escrow account 
pending the occurrence of th escrow rel as v nt Debiting of th escrow account 
and crediting of the s Iter's financial account for th amount of the funds transfer 
occurs once th screw releas event has transpired and th purchaser has not 
rejected the shipment 

In another exemplary embodiment, the transaction mechanism 202 may be 
suitably configured to include a transaction fee in the amount debited from the 
purchaser's financial account, and/or the transaction mechanism 202 may be suitably 
configured to subtract a transaction fee from the amount credited to the seller's 
financial account. In an exemplary embodiment, the transfer of funds to the seller's 
financial account from the escrow account includes suitable communications with an 
ACH, as will be appreciated by one of ordinary skill in the art 

In an exemplary embodiment, the transaction mechanism 202 provides value- 
added services which may be requested by the purchaser 204 and/or the seller 206 as 
a part of the transaction between the parties. Preferably, the value-added services 
may include insurance, dispute resolution, postal tracking, and/or similar services that 
potentially enhance the value of the transaction to the purchaser 204 and/or the seller 
206. In the event that value-added services are requested by the purchaser 204 as a 
part of the funds transfer, then the cost of such services is included in the amount of 
funds debited or deducted from the purchaser's financial account Likewise, the cost 
of value-added services requested by the seller 204 are suitably withheld or deducted 
from the funds credited or added to the seller's financial account 

In accordance with another aspect of the present invention, FIG. 3 is a diagram 
illustrating an exemplary transaction system 300. The transaction system 300 
comprises an intermediary 314 which suitably provides an interface between the 
purchaser 304 and the seller 306. The intermediary 314 can be any suitable third 
party. In an exemplary embodiment, intermediary 314 can include an online auction 
such as eBay® or eWanted®, an online merchant such as Amazon.com®, an online 
classified ad site, and/or the like. By way of example, if the intermediary 314 is eBay, 
the seller 306 may list goods for sale through the intermediary 314, for which a 
purchaser 304 may then submit bids. The intermediary 314 then suitably determines 
whether the purchaser 304 submitted the highest bid and, if so, then makes a final sale 
determination, which can include sending appropriate notice, such as by e-mail for 
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xarnple, to both the purchaser 304 and the sell r 306. Once notiti d, th purchaser 
304 is provided with th opportunity to select means for submitting payment to the 
seller 306, such as through a suitabl card or DDA. Forexampl , by selecting the card 
paym nt method, transaction information regarding the sale is transferred by 
5 intermediary 314 to a suitable transaction mechanism 302 provided by a suitable 
financial institution, such as a card issuer. 

As described above with reference to FIG. 2, the seller 306 preferably is pre- 
registered with the transaction mechanism 302, and the seller's financial account at the 
seller's financial institution 308 may suitably receive appropriate funds transferred from — — 

10 the purchaser's financial account at the purchaser's financial institution 310. If the 
purchaser 304 is not pre-registered, purchaser registration may take place at the time 
of the transaction with the seller 306. As discussed above, the transaction mechanism 
302 receives transaction information regarding the sale, authenticates the purchaser 
304 and the seller 306, and performs suitable credit and fraud risk management 

15 analyses. If the purchaser 304 has sufficient funds available in their financial account 
and the risk management and authentication processes do not result in a negative 
determination, then the transaction mechanism 302 deems the transaction acceptable 
and debits suitable funds from the purchaser's financial account Preferably, as 
described above with reference to FIG. 2, a suitable escrow account maintained by the 

20 transaction mechanism 302 is credited with the funds transferred from the purchaser's 
financial account Upon the occurrence of a suitably predefined or pre-identified 
escrow release event, the escrow account is suitably debited and the seller's financial 
account is suitably credited with the funds. Again, as described above, any suitable * 
' transaction or service fees are preferably included in the amount of funds debited and 

25 transferred from the purchaser's financial account and/or deducted from the amount of 
funds disbursed and credited to the seller's financial account 

As is often the case with an intermediary 314, such as eBay, the transaction 
between the seller 306 and the purchaser 304 may involve the shipment of goods from 
the seller 306 to the purchaser 304. Consequently, as typically determined by the 

30 particular business rules of the intermediary 314, the goods are shipped by a suitable 
shipping agent 316 from the seller 306 to the purchaser 304. Preferably, as a part of 
the escrow service performed by the transaction mechanism 302, a tracking number 
will be provided by the shipping agent to the transaction mechanism 302. Upon 
confirmation that the purchaser 304 has received the goods, the transaction 
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mechanism suitably transfers the appropnat tunds to in sellers tinanaai account 
Pref rably, th shipping agent 316 confirms that the purchaser 304 has received th 
goods. More preferably, th transaction mechanism 302 only releases th funds to the 
seller 306 upon the suitabl occurrence of any predefined escrow rel as event, such 
5 as the lapse of a specified period of time in which the purchas r 304 may valuate and 
either accept or reject the goods. In the case that the escrow release event is not 
satisfied or that the purchaser 304 rejects the goods, the transaction may be suitably 
reversed or otherwise abandoned. In the event that there is a dispute between a 
purchaser 304. and a seller 306 regarding a particular transaction, the financial 

10 institution that maintains the transaction mechanism 302 may provide the parties with a 
suitable dispute resolution mechanism, such as access to any suitable system for 
providing customer service for example. 

In an exemplary embodiment, anonymity or portions of anonymity between the 
purchaser 304 and seller 306 is suitably maintained throughout the transaction 

15 between the parties. One skilled in the art will appreciate that any subset of 
information may remain anonymous. Preferably, the only purchaser information that is 
transmitted and known to the seller 306 is the purchaser's user identifier. Likewise, it 
is preferred that the purchaser's knowledge of the seller 306 is limited to the seller's 
user identifier. In other words, both the purchaser 304 and the seller 306 need not 

20 disclose their name, address, financial account information, or any other confidential 
information to one another in order to effect the transaction. In this embodiment, the 
purchaser 304 and seller 306 suitably provide their name, address, financial account 
information, and any other necessary information to the transaction mechanism 302 
upon registering with the tran^ctionkmechanism 302. In this manner, the shipping 

25 agent 316 suitably obtains the relevant purchaser shipping information from the 
transaction mechanism 302 to obviate any need for a seller 306 to have access to 
confidential identification information of a purchaser 304. 

It should be understood that while FIG. 3 illustrates respective communication 
links between the transaction mechanism 302 and both the purchaser 304 and the 

30 seller 306, the scope of the present invention extends to the transmission of 
information, such as registration information, transaction information, and/or the like, 
from either or both of the purchaser 304 and/or the seller 306 directly to the 
intermediary 314 and then from the intermediary 314 to the transaction mechanism 
302. In other words, the intermediary 314 may mediate the flow of information from 
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either/both the purchaser 304 and/or th seller 306 to th transaction mechanism 302 
without any direct communication between the ither the purchaser 304 or the seller 
306 and the transaction mechanism 302. Moreover, the intermediary 314 may 
communicate directly with th transaction mechanism 302 through a suitable 
5 communications link or, alternatively, the transaction mechanism 302 may be 
integrated with the intermediary 314, as illustrated in the exemplary transaction system 
400 of FIG. 4. In accordance with this aspect of the present invention, the transaction 
mechanism 402, which is integrated with the intermediary 414, provides substantially 
the same functionality as the exemplary transaction mechanisms described above with— 

1 0 reference to FIGS. 2 and 3, respectively. 

With reference to FIG. 5, an exemplary transactional mechanism 502 includes a 
central processor 504 in communication with other elements of the transaction 
mechanism 502 through a system interface or bus 506. A suitable display device / 
input device 508, such as a keyboard or pointing device in combination with a monitor, 

15 may be provided for receiving data from and outputting data to a user. A memory 510 
associated with the transaction mechanism 502 preferably includes a transactional 
control module 512, a risk management module 514, and an authentication module 
516. The memory 510 preferably further includes an operating system 518 which 
nables execution by processor 504 of the various software applications residing at 

20 transaction control module 512, risk management control module 514, and 
authentication module 516. Operating system 518 may be any suitable operating 
system, such as any version of Windows, MacOS, BeOS, Linux, UNIX, and/or the like. 
Preferably, a network interface 520 is provided for suitably interfacing with other 
elements of the transaction ^stem^such as the elements described above with 

25 reference to FIGS. 2-4. Lastly, a storage device 522, such as a hard disk drive for 
example, preferably contains suitable files which are suitably accessed by the 
transaction control module 512, the risk management module 514, and the 
authentication module 516. 

In particular, customers' transaction records file 524 preferably comprises 

30 transaction information of customers who are registered with the transaction 
mechanism 502, which transaction information is used to perform suitable credit risk 
and fraud risk analyses. Likewise, customers' information records 526 comprises 
information received either from a purchaser or a seller upon registration with the 
transaction mechanism 502 or during the maintenance of the appropriat financial 
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account As used herein, a "customer may be either a purchaser or a seller who has 
a financial account with the financial institution which suitably maintains the transaction 
mechanism 502 and who is registered with the transaction m chanism 502. 
Accordingly, providing the transaction mechanism 502 with access to the appropriate 

5 transaction records and information records of the parties involved in the funds transfer 
facilitates essentially real time risk management by the risk management module 514. 
Similarly, authentication of the parties to the transaction may likewise be performed 
efficiently by the authentication module 516, which preferably has access to the 
records residing in storage device 522: One skilled in the art will appreciate that4he 

10 storage device 522 and, therefore, customer transaction records 524 and customer 
information records 526 may be co-located with the transaction mechanism 502, as 
illustrated in FIG. 5, or may be remotely located with respect to the transaction 
mechanism 502. If the storage device 522 is remotely located with respect to the 
transaction mechanism 502, communication between storage device 522 and 

15 transaction mechanism 502 may be accomplished by any suitable communication link 
but is preferably accomplished through a private Intranet or extranet 

Referring next to FIGS. 6 and 7, as discussed, the process flows depicted in 
these figures are exemplary embodiments of the invention only and are not intended to 
limit the scope of the invention as described above. FIG. 6 is a flow diagram 

20 r presenting an exemplary process for facilitating a commercial transaction between a 
purchaser and a seller. In accordance with the present invention, an exemplary 
process executed by a suitable transaction mechanism may include any of the 
following: registering a purchaser with the transaction mechanism (step 602); 
registering a seller with the trans^ction^mechanism (step 604); receiving agreed upon 

25 transaction terms from at least one of a purchaser and a seller (step 606); receiving a 
purchaser's selection of a method for transferring monetary value to a seller (step 608); 
receiving transaction information from at least one of a purchaser and a seller (step 
610); performing authentication, credit risk, and/or fraud risk analyses (step 612); 
determining whether the transaction is acceptable (step 614); terminating the 

30 transaction if the transaction is not acceptable; debiting funds from a purchaser's 
financial account if the transaction is acceptable (step 616); holding the funds in an 
escrow account (step 618); releasing the funds from the escrow account and 
disbursing the funds to the seller's financial account (step 620); and crediting the funds 
to a s Iter's financial account (step 622). 
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In accordance with the present invention, any purcnas r having a tinanaai 
account can transfer funds from the purchaser's financial account to the financial 
account of a second party. For exampl , a purchaser having a card can transfer funds 
from the purchaser's card to the card or demand deposit account of any second party 
5 having such an account As represented in FIG. 6 by step 602, the purchaser 
preferably pre-registers with a transaction mechanism, which transaction mechanism 
can be established and maintained by any suitable third party, such as a card issuer, 
as described above with reference to FIGS. 2 and 3. To register with the transaction 
mechanism, the purchaser may-submit suitable purchaser registration informatiorv- 

10 such as information establishing the identity of the purchaser and information 
regarding the purchaser's financial account. The purchaser registration information 
can be suitably stored by the transaction mechanism, such as by storage device 522 of 
FIG. 5. The purchaser may communicate with the transaction mechanism by any 
means of communication known to those skilled in the art, including communications 

15 by telephone or through the use of any form of computer or point of interaction device 
having a means for communication, such as a modem, suitable wireless means for 
communication, and/or the like. If the transaction mechanism is maintained by the 
purchaser's financial institution, the purchaser can suitably register with the transaction 
mechanism at the same time that the purchaser initially completes the application for 

20 the financial account Alternatively, the purchaser can register with the transaction 
mechanism at any suitable time, including at the time of a transaction with a seller. 

The purchaser registration information which may be used by the transaction ; v 
mechanism can include any suitable information, such as any of the types of ^ 
information described above with reference to FIG. 2. Upon submission of such 

25 information to the transaction mechanism, the transaction mechanism may then issue 
to the purchaser a unique user identifier, such as an identification number, code, 
password, pass phrase, and/or other suitable identifier which may be used by the 
transaction mechanism to identify the purchaser. In this manner, the purchaser's user 
identifier can be used by the transaction mechanism to identify and suitably access the 

30 purchaser's registration information at the time of a transaction between a purchaser 
and a seller. The user identifier can comprise any number or combination of letters, 
digits, or other characters. If the transaction mechanism is accessible through the 
Internet and especially if the purchaser registers with the transaction mechanism 
through an interface at an Internet Web page, the transaction mechanism or entity 
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maintaining the transaction mechanism can e-mail the appropnate us r laentm r to tne 
purchaser, optionally using any well-known means for secure communications, such as 
suitabl encryption. 

As indicated at step 604, th seller preferably also registers with the transaction 
5 mechanism. Although FIG. 6 illustrates the registration of a seller with the transaction 
mechanism subsequent to the purchaser's registration, the seller can register with the 
transaction mechanism at any suitable time, including prior to the purchaser's 
registration and at the time of the transaction with the purchaser. As with the 

purchaser, the seller preferably provides the transaction melanism with registration 

10 information to identify the seller and to identify the seller's appropriate financial 
account, such as a card or a demand deposit account, to which the transaction 
mechanism may transfer funds. The seller's registration information may include any 
suitable information, such as the seller's name, location or address, social security 
number (if appropriate), federal employer identification number, financial account 

15 number, financial institution, and/or any other suitable information that may be 
pertinent to a funds transfer transaction. If the seller is associated with the financial 
institution that is providing the transaction mechanism, the seller's registration 
information can be suitably stored by the storage device shown in FIG. 5. 
Furthermore, as with the purchaser, the seller suitably receives from the transaction 

20 mechanism a user identifier which identifies the seller to the transaction mechanism. 
After the purchaser and seller are registered with the transaction mechanism, as 
illustrated in steps 602 and 604, the purchaser and seller can suitably agree upon the r 
terms of a transaction, as shown in step 606. s 
The transaction illustrated irvstep 606 may be an exchange of goods or services 

25 for value, although this is not required. The transaction, for example, could include a 
transaction where the purchaser is gratuitously transferring funds from the purchaser's 
financial account to the financial account of the seller, thereby eliminating the need for 
a reciprocal exchange. The purchaser and seller may enter into the transaction 
through the Internet, such as where a purchaser seeks to purchase goods, services, or 

30 other value from an Internet Web site operated by the seller for example. Alternatively, 
the purchaser and seller can agree to enter into the transaction in a more conventional 
manner, such as through person-to-person communication over the telephone or in 
person for example. The particular terms of the transaction between the purchaser 
and the seller may include any suitable terms that are agreeabl" to the parties and 
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may address issues such as the nature or any goods, services, or otn r vaiu ; tn 
amount of the funds that are to be transferred from the purchaser's financial account to 
th s II r's financial account; th nature and definition of any scrow release event; the 
antictpat d date or window for delivery or shipment of any goods, services, r other 
5 value; and/or other suitable terms and conditions pertaining to the transaction. 

After the purchaser and seller have agreed upon the terms of the transaction, 
the purchaser may be requested to select a method for transferring suitable funds to 
the seller, as indicated in step 608. The selection of a method for transferring the 

necessary funds may be completed through the transaction mechanism „or,_. 

10 alternatively, through any other suitable means and then suitably communicated to the 
transaction mechanism. For instance, where the purchaser is purchasing goods, 
services, or other value from an online seller via an Internet Web site, the Web site, 
rather then the transaction mechanism, can request that the purchaser select a 
method of transferring monetary value to the seller. After the purchaser suitably 

15 responds to the query, such as through a pop-up display generated by the Internet 
site, the purchaser's response may be suitably communicated to the transaction 
mechanism. Alternatively, the purchaser can select a funds transfer method directly 
through the transaction mechanism, which may occur in the case where the particular 
Internet site does not request such information but, rather, allows the transaction 

20 mechanism to issue the relevant query. Additionally, the latter circumstance may 
occur in the case where a purchaser is transacting with a seller through a site which 
maintains the transaction mechanism, such as an online sales site maintained by a 
card issuer. 

In addition to selecting a method^for transferring funds to a seller, such as 
25 through a card or DDA transaction, the purchaser may also select one or more value- 
added services, as indicated in step 608. For example, where the transaction 
mechanism is maintained by a card issuer, the purchaser may be able to select value- 
added services provided by the card issuer, such as purchaser's insurance, shipping 
alternatives (where the purchaser has purchased goods or, alternatively, services 
30 which may be embodied in documents of any suitable type), postal tracking 
alternatives, dispute resolution to mediate any dispute that may arise between the 
purchaser and seller regarding the transaction, and/or the like. It will be appreciated 
by those of skill in the art that additional value-added services may be offered by the 
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s Her in addition to those offered by the third party entity maintaining the transaction 
mechanism. 

Aft r s lecting a funds transf r method and any value-added services, th 
purchaser and/or seller may provide suitabl transaction information to th transaction 

5 mechanism for authentication, credit risk analysis, and/or fraud risk analysis, as 
represented in step 610. The transaction information can include, but is not limited to, 
the amount of funds to be transferred between the purchaser and seller, the date and 
time of the transaction, a description of the transaction, the purchaser's and seller's 
respective unique user Identifiers, and any other pertinent information which may-- _ 

10 suitably identify the transaction as well as both the purchaser and the seller. For 
example, the transaction information can include a date and time at which the transfer 
of funds should take place. In this manner, the purchaser and sella* can indicate that 
the transfer of funds can take place at a specific time in the future. Upon receiving the 
transaction information, the transaction mechanism can look-up and access the 

15 customer information records, which preferably include at least one of the purchaser's 
and the seller's registration and financial account information. As discussed above, 
this information preferably includes data such as the purchaser's financial account 
identifier and/or the seller's financial account identifier, as well as any additional 
information that has been suitably input in steps 602 and 604, above. 

20 Thereafter, as represented by step 612, the transaction mechanism may 

suitably determine whether the transaction is acceptable. In an exemplary 

mbodiment, one component of this determination utilizes the transaction information c 
and the purchaser and/or seller registration information to execute a fraud analysis, as 5 
represented by step 614. For &amp1§r where the transaction mechanism is 

25 established and maintained by a card issuer and the purchaser is a cardholder of a 
card issued by the card issuer, the card issuer can maintain a history of the 
purchaser's card transactions. Such card transaction history can be suitably stored 
along with the purchaser registration information in the customer information records or 
the customer transaction records, as described above. Using this historical 

30 information, the risk management module of the transaction mechanism can perform a 
fraud analysis by executing a fraud detection program or mechanism to determine 
whether the current transaction, or current transaction in view of recent transactions, is 
indicative of fraud. For example, where a card has been utilized to purchase multiple 
high-priced it ms, th fraud analysis may flag the transaction such that the transaction 
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mechanism will terminat or oth rwise not permit th purchaser to complet the 
transaction. The fraud detection mechanism may suitably end the transaction, as 
represented by the negativ outcome of st p 612, or, alternatively, may query the 
purchaser to determin whether th purchaser is actually the proper cardhold r. In the 
case of terminating the transaction without presenting further queries to the purchaser, 
the purchaser and/or the seller may be contacted through any suitable means, such as 
a real time display, e-mail, telephone, and/or the like, to notify the purchaser and/or the 
s Her that the transaction was not completed. 

The transaction mechanism's determination regarding the acceptability of the - 
transaction may suitably include a second component, namely a credit analysis, as 
represented by step 615, which effects a comparison of the user identifiers of 
either/both the purchaser and the seller with the user identifiers stored in the storage 
device to determine whether the transaction is acceptable. After suitably identifying 
the accounts of the parties entering into the transaction, the transaction mechanism 
may suitably analyze whether the transaction is acceptable based upon additional 
criteria. The analysis for determining transaction acceptability can be suitably 
implemented through a computer-readable storage medium encoded with processing 
instructions, as described above. Such analysis can include a determination of 
whether the purchaser has sufficient credit or funds in the financial account to 
complete the transaction. Additionally, in the event that the purchaser uses a card to 
accomplish the funds transfer to the seller, the transaction mechanism may suitably 
terminate the transaction if it determines that the purchaser's card has expired, has 
been reported as lost or stolen, or is otherwise invalid. Where the transaction 
mechanism determines, through a pJOgrampor any other suitable means, that the 
transaction cannot be completed properly, the transaction mechanism will not complete 
the transaction, as seen in the negative outcome of step 612. When a negative 
outcome occurs, the purchaser and/or the seller may be contacted through any 
suitable means, such as a real time display, e-mail, telephone, and/or the like, to notify 
the purchaser and/or the seller that the transaction was not completed and to provide 
particular reasons for the termination of the transaction. 

Once a transaction is deemed to be acceptable, the transaction mechanism 
suitably completes the transaction by debiting the purchaser's financial account, as 
represented by step 616. Preferably, the transaction mechanism then transfers the 
funds to a suitable escrow account and holds the funds in the escrow account until a 
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suitable escrow release event has transpired, as represented by step 618. Once the 
escrow rel as event has transpir d, the funds are then rel ased from th screw 
account and disbursed to th seller's financial account, as represented by st p 620. In 
accordance with th terms of the transaction as agreed to by the purchaser and the 
5 seller, the funds then are disburs d to the seller's financial account and the seller's 
account is suitably credited with the funds, as represented by step 622. The 
transaction mechanism may automatically include any suitable transaction fees, as a 
service charge for the transaction, in the funds debited from the purchaser's financial 
-account and/or may automatically-deduct such fees from the funds disbursed to. the 

1 0 seller's financial account. 

FIG. 7 is a flow diagram of the operation of an exemplary transaction 
mechanism in accordance with the present invention. As described above with 
reference to FIG. 6, the transaction mechanism preferably first receives registration 
information from the purchaser and the seller, as indicated by steps 702 and 704. 

15 Registration information may be entered by a purchaser and/or a seller using any well- 
known input device, such as a keyboard or mouse suitably connected to any type of 
computer which can suitably communicate with the transaction mechanism. The 
registration information may then be transmitted to the transaction mechanism either in 
real time or downloaded to the transaction mechanism after the registration information 

20 is input by the purchaser and/or the seller. 

Optionally, as is shown in step 706, the transaction mechanism may receive an 
indication that a transaction between a purchaser and a seller has been initiated. This v 
indication may originate from either the purchaser or the seller or, alternatively, from an ^ 
intermediary, which may be unrelated^ to the^entity which maintains the transaction 

25 mechanism. For example, a purchaser may choose to transfer funds using an 
interface located at an intermediary's Web site. This type of funds transfer might occur 
after the intermediary has suitably queried the purchaser as to the purchaser's 
preferred funds transfer method, such as by issuing a query by using any of several 
conventional graphical interfaces or pop-up graphics that are well-known in the art 

30 Alternatively, the seller may suitably initiate the transaction. 

Thereafter, as represented by step 708, the transaction mechanism receives 
suitable information regarding the purchaser's selected method for transferring funds 
to the seller, such as by a card or DDA for example, and any selected value-added 
services, as described above. This step may be facilitated by any suitable mechanism, 
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such as a suitable network connection, sucn as an internet connection, or tnrougn any 
suitable input d vice associated with th transaction mechanism. Preferably, at I ast 
one of the purchaser and th seller provides suitabl transaction information to th 
transaction mechanism for auth ntication, credit risk, and fraud risk analyses. Once 
5 the transaction mechanism receives suitable transaction information, as represented 
by step 710 and as described in greater detail above, the transaction mechanism 
suitably determines whether the transaction is acceptable, as represented by step 712. 
The fraud detection mechanism executed by the risk management module of the 
_ ... transaction mechanism then suitably communicates with. the_ customer transaction 

10 records and customer information records to determine whether the transaction 
represents a potential fraud risk, as represented by step 714 and as described in 
greater detail above with reference to FIG. 6. 

After the fraud detection mechanism has been executed, the transaction 
mechanism may then suitably perform a credit analysis, as represented by step 715, to 

15 compare the user identifiers trf either/both the purchaser and the seller to the user 
identifiers stored in the storage device in an additional effort to determine whether the 
transaction is acceptable. As described above with reference to FIG. 6, after suitably 
identifying the accounts of the parties entering into the transaction, the transaction 
mechanism also may, suitably determine whether the purchaser has sufficient credit or 

20 funds in the financial account to complete the transaction. Additionally, in the case that 
the purchaser uses a card to effect the funds transfer to the seller, the analysis can 
further include a determination of whether the card has expired, has been reported as £ 
I st or stolen, or is otherwise invalid. Where the transaction mechanism determines, £ 
through a program or any other suitable means, that the transaction cannot be 

25 completed properly, the transaction mechanism will not complete the transaction, as 
seen in the negative outcome of step 712. When a negative outcome occurs, the 
purchaser and/or seller may be contacted through any suitable means, such as a real 
time display, e-mail, telephone, and/or the like, to notify the purchaser and/or the seller 
that the transaction was not completed and to provide particular reasons for the 

30 t rmination of the transaction. 

Once the transaction is deemed acceptable, the transaction mechanism 
completes the transaction by debiting the purchaser's account, as represented by step 
716. Preferably, the transaction mechanism then transfers the funds to a suitable 
escrow account and holds the funds in the scrow account until a suitable escrow 
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release vent has transpired, as r presented oy step unce in transaction 

mechanism receives information indicating that the scrow releas vent has 
transpired, as represented in step 720, the funds are then released from th scrow 
account and disbursed to the s Iter's financial account, as repres nted by step 722. 
5 The transaction mechanism also may automatically account for any suitable 
transaction fees, as a service charge for the transaction, by suitably including any such 
fees in the funds debited from the purchaser's financial account and/or by suitably 
deducting any such frees from the funds disbursed to the seller's financial account 

Referring now to FIG. 8, another exemplary embodiment .. of. the present 

10 invention includes an auction intermediary 814, such as eBay, and a shipping service 
816, such as Federal Express®, United Parcel Service®, and/or any other suitable 
shipping service. In this embodiment, the seller 806 and/or the purchaser 804 initially 
register with the transaction mechanism 802. Preferably, the seller 806 lists goods for 
sale at the Web portal provided by the auction intermediary 814, which listing results in 

15 a bid on the goods submitted by a purchaser. The auction intermediary 814 then 
determines who has submitted the highest bid and notifies both the high-bidding 
purchaser and the seller. The purchaser 804 then selects a method for transferring 
suitable funds to the seller, such as by a suitable transaction card or DDA. At the time 
of the transaction, the purchaser may also be presented with the option of selecting 

20 one or more value-added services. The purchaser transaction information is then 
suitably transmitted to the transaction mechanism 802. Likewise, the seller suitably 
provides the transaction mechanism 802 with suitable seller information for v * * 
authentication purposes. The transaction mechanism 802 then performs suitable risk 
management analysis to determine wh@ther~tbe proposed transaction is associated 

25 with any credit and/or fraud risks. If the purchaser 804 has sufficient funds available to 
complete the transfer and if both the purchaser 804 and the seller 806 are 
authenticated (and assuming that the credit and fraud risk analyses do not result in a 
negative determination), then the transaction mechanism 802 suitably debits the 
purchaser's card or DDA by the amount of the purchase price as well as the cost of 

30 any selected value added services. The transaction mechanism 802 then sends a 
confirmation to the seller 806 that the purchaser's account has been debited. 
Preferably, the transaction amount then is suitably held in an escrow account 
maintained by the transaction mechanism, and once the shipping service 816 acquires 
the goods from the seller for shipment to the purchaser, the transaction mechanism 
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802 receives a tracking number from the shipping service 816. Depending upon the 
nature of th screw, th transfer of funds to the seller's card or DDA will b delayed 
accordingly. For exampl , the escrow may be based upon a 3-day waiting period 
following notification to the transaction mechanism 802 of th receipt of the goods by 
5 the purchaser 804, which notification may be received directly from the purchaser 804 
or from the shipping service 816. Accordingly, the transaction mechanism 802 
disburses the appropriate funds to the seller's DDA (minus any transactional fee) at the 
seller's bank, which suitably credits the funds to the seller's financial account If 

selected by either the purchaser or the seller, value-added services, such as _ 

10 purchaser's insurance and dispute resolution, may be provided as needed. 

Exemplary Transaction Flow 

As will be appreciated by one skilled in the art, the present invention admits of 
various aspects which may be implemented in any of several ways. FIGS. 9-20 

15 illustrate the flow of an exemplary transaction implemented in accordance with 
particular aspects of the present invention. However, it should be understood that this 
transaction flow is exemplary only and is not intended to limit the scope of the present 
invention as described above. 

With reference to FIG. 9, an exemplary user registration process 902 begins 

20 when an individual 904, such as an Internet user, accesses the transaction mechanism 
and requests registration with the transaction mechanism. Internet user 904 may be 

ither a potential purchaser or a potential seller. As illustrated in the exemplary - 
interface of FIG. 10, an Internet user may suitably register with the transaction ^ * 
mechanism by activating hyperlink 1002f? whicfe^activation preferably results in the 

25 display of the terms and conditions for registration and a request that an Internet user 
input suitable registration information, as described in greater detail above. 

Once an Internet user 904 has registered with the transaction mechanism, the 
Internet user 904 may then suitably request to be togged into the transaction system, 
as represented by step 906 of FIG. 9. As illustrated in the exemplary transaction 

30 mechanism main page of FIG. 1 1 , an Internet user may suitably request the login page 
by activating hyperlink 1102, which activation preferably results in the display of a login 
page having suitable datafields. The datafields may request any suitable login 
information from an Internet user. Such login information may include, for example, a 
request for the Internet user's unique user identifier and a password or pass phrase. 

30 
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Once the Internet user submits th requ sted information, the Int met user is suitably 
logged into the transaction system. If the Internet user submits an invalid user 
identifier and/or password, an error message is suitably displayed, and the Internet 
us r is requested to re-enter and re-submit the information. Once th Internet user is 
5 logged into the transaction system, the transaction system retrieves the list of 
registered card and DDA accounts held by the Internet user and displays a suitable 
interface, such as the exemplary interface of FIG. 12, which may provide any suitable 
means for either conveying information to or receiving information from the Internet 

- user. As illustrated in the exemplary embodiment represented -in FJG. 12, the 

10 transaction system preferably provides means for initiating a transaction, such as tab 
1202 for example, and may suitably display the Internet user's transaction history, as 
represented by data table 1204. Suitable data access options, such as hyperlinks 
1206 and 1208, may be provided to enable the Internet user to access any suitable 
information that may be provided by the transaction system, such as information 

1 5 pertaining to other registered financial accounts and/or means for registering additional 
financial accounts with the transaction mechanism. 

With momentary reference to FIG. 9, in an exemplary embodiment, Internet user 
904 may be either a seller 908 or a purchaser 910. If Internet user 904 is a seller 908 
who is suitably registered and logged into the transaction system, the seller 908 may 

20 suitably initiate a transaction through the transaction mechanism. In an exemplary 
embodiment, there are preferably two aspects involved in a seller-initiated transaction. 
First, the seller 908 suitably creates a transaction invoice, as represented by step 912. 
Then, the purchaser 910 preferably confirms or accepts the transaction, as 
represented by step 914. Preferably, at any givessrpoint during the transaction, either 

25 the seller 908 or the purchaser 910 may either cancel (step 916) or reverse (step 918) 
the transaction. In the event that a purchaser 910 or a seller 908 experiences any 
difficulty with the transaction mechanism or if there is a dispute between the seller 908 
and the purchaser 910, a customer service representative 920 associated with the 
third party entity which is providing the transaction mechanism may suitably provide 

30 any desired customer service and/or dispute resolution (step 922). 

FIG. 13 next illustrates an exemplary process for initiating a commercial 
transaction between a seller and a purchaser. In this exemplary embodiment, a seller- 
initiated transaction preferably begins when the seller submits a request to start a 
transaction, such as by activating tab 1202 of FIG. 12. Once the transaction 
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mechanism receives th request, the transaction mecnanism determines wh tner the 
s II r is a regist red user (step 1304). If the seller is not a registered user, the 
transaction m chanism provid s a suitable registration interface (step 1306), such as 
d scribed abov with reference to FIG. 10. If th seller is a regist red user, the 
5 transaction mechanism provides a suitable means for initiating the transaction (step 
1308), such as by providing the exemplary interface of FIG. 14. 

The seller then suitably provides the information requested by the transaction 
mechanism (step 1310). For example, the seller enters the appropriate information 
which may be requested by various transaction datafields provided by toe transaction- 

10 mechanism through a suitable user interface, such as the exemplary transaction 
invoice entry page 1400 of FIG. 14. The transaction datafields provided by a suitable 
transaction entry interface may include suitable datafields of any number or form, such 
as, for example, a datafield 1402 for a prospective purchaser's email address; a 
datafield 1404 indicating a final date for the acceptable transfer of funds to the seller; a 

15 datafield 1406 for indicating the seller's reference number a datafield 1408 for a 
transaction description, such as the identification of any intermediary, like eBay, which 
may be involved in the transaction; datafields 1410 for a description of the particular 
items that will be the subject of the transaction; datafields 1412 for indicating the 
appropriate quantity of each item described in datafield 1410; datafields 1414 for 

20 indicating the appropriate price for each item described in datafield 1410; datafields 
1416 for indicating the subtotal amount or extended price associated with the quantity 
and price for each item described in datafield 1410; a datafield 1418 for indicating a 
suitable cost for any desired value-added services, such as insurance, dispute 
resolution, postal tracking, or any other suitable vatee-added service; a datafield 1420 

25 for indicating the cost associated with any shipping and handling charges; datafield 
1422 for indicating any miscellaneous charges that may be associated with the 
transaction, such as any applicable taxes for example; and a datafield 1424 for 
indicating a total charge or total amount of funds to be transferred from the purchaser 
to the seller upon completion of the transaction. Additional information that may be 

30 requested from the Internet user may include toe email address of the Internet user, 
any optional email message intended for the purchaser, and/or any other suitable 
information. 

Additionally, a suitable transaction entry interface may include any number or 
form of tabs, such as tab 1426 which activates the creation of additional datafields 
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1410. Th additional tab or tabs may be used by the seller to activate or implement 
any suitabl function which may furth r facilitat th transaction between th seller and 
the purchaser. For exampl , transaction invoice entry page 1400 may also includ an 
additional datafi Id, or tab for accessing an additional datafield, which may request that 
5 the seller provide suitable information regarding an escrow release event. Such 
scrow release event information may include a particular time period within which a 
purchaser may either accept or reject any items prior to the transfer of funds from the 
escrow account to the seller's account, such as a particular number of days after the 
.... purchaser receives goods, f seivices, orother value from asuitable shipping agent 

10 In addition to entering the appropriate information which may be requested by 

the various transaction datafields provided by the transaction mechanism, the seller 
preferably is further requested to select a suitable financial account which will 
ultimately receive the funds transferred from the purchaser at the completion of the 
transaction. Preferably, the various options presented to the seller on the transaction 

15 entry interface reflect the financial account or accounts provided by the seller during 
the seller's registration with the transaction mechanism, as described above. The 
financial account selection options may include any suitable selection options which 
provide the transaction mechanism with the appropriate information. As illustrated in 
exemplary transaction invoice entry page 1400, financial account selection options 

20 may include selection options 1428 and 1430 which preferably indicate the type of 
financial account 1428, such as a credit card or a demand deposit account (DDA), and 
the financial account identifier 1430, such as a credit card number or a DDA number. 

As one skilled in the art will appreciate, the above described transaction entry 
interface, as well as any or all other aspects of the present invention, may include any 

25 suitable form of encryption and/or other security measures either currently known or 
hereafter devised. 

Once the seller completes a suitable transaction entry interface, the seller may 
either submit or cancel the transaction invoice entry (step 1312). If the seller cancels 
the transaction invoice entry, such as by activating tab 1432 of FIG. 14, the seller is 
30 returned to the transaction mechanism main page (step 1314), such as the exemplary 
transaction mechanism main page illustrated in FIG. 11. If the seller submits the 
transaction invoice entry page to the transaction mechanism by activating, for example, 
a suitable tab, such as tab 1432, or by pressing the enter key on a suitable input 
device, a transaction invoice is th n displayed by the transaction mechanism (step 
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1316). The transaction invoice may includ any suitaDie intormation entered oy me 
seller on th transaction entry interface and any other relevant information, such as 
any transaction or service fees charged by the transaction mechanism. As illustrated 
in the exemplary transaction invoice 1500 of FIG. 15, such information may includ any 
5 or all of the entries corresponding to th datafi Ids described abov with reference to 
FIG. 14. In addition, the transaction invoice may include an invoice number 1536 
which may be automatically assigned by the transaction mechanism; an additional 
service fee amount 1538 which may be suitably deducted from the amount of funds 
transferred-from the purchaser, a total amount 1 540, net of fees^owed to the seller at 

10 the completion of the transaction; the date 1542 that the transaction invoice was 
created; and a status indicator 1544, which may include any suitable indicator of any 
suitable status that may be relevant to the transaction as of the display date of the 
transaction invoice, such as any of the exemplary status indicators illustrated beneath 
status key 1546 (i.e., paid, waiting on purchaser, declined by purchaser, and expired). 

1 5 After the seller completes a review of the transaction invoice, the seller may 

either decline or accept the transaction invoice (step 1318). If the seller declines the 
transaction invoice, such as by suitably activating tab 1548 of FIG. 15 for example, a 
suitable transaction interface is displayed (step 1319). such as exemplary cancel 
transaction page 1600 of FIG. 16, which may provide suitable means, such as tabs 

20 1602 and 1604, for either initiating a new transaction or returning to the transaction 
mechanism main page. If the seller accepts the transaction invoice, such as by 
suitably activating tab 1550 of FIG. 15 or pressing the enter key on a suitable input t 
device for example, the transaction invoice is suitably stored by the transaction^ 
mechanism in a suitable storage device (step-1320)^Then, the transaction invoice is 

25 preferably transmitted to both the purchaser and the seller by any suitable method, 
such as by email, facsimile, mail, and/or the like (step 1322). Preferably, the 
transaction invoice is transmitted via email to the respective email addresses of the 
purchaser and the seller. 

Once the seller's transaction invoice is transmitted to the purchaser, the . 

30 transaction may be suitably completed when the purchaser accepts the transaction. In 
the exemplary embodiment illustrated by the flowchart of FIG. 17, when the purchaser 
receives a transmission from the transaction mechanism regarding the transaction 
invoice (step 1702), such as an email transmission having a hyperlink to a suitable 
purchaser transaction interface, the purchaser may follow the link to the transaction 
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interface (step 1704), such as the xemplary purchaser transaction review page 18UU 
of FIG. 18, to review the terms and conditions of the transaction as set forth by the 
seller As illustrated in FIG. 17, a purchaser may accept a transaction by on of at 
least three methods, wh rein the m thods are indicated by phantom lines to repres nt 
5 the purchaser's optional courses of action. First, the purchaser may accept the 
transaction using a suitable card without logging into the transaction system (step 
1706). Second, the purchaser may accept the transaction by suitably logging into the 
transaction system and selecting a suitable card to transfer funds to the seller (step 
1708), Finally, the purchaser may accept the transaction by- suitably- logging JntoJhe 
10 transaction system and selecting a suitable DDA to transfer funds to the seller (step 
1710). 

In the first case, the purchaser accepts the transaction with a suitable card 
without logging into the transaction system. If the transaction terms and conditions are 
acceptable to the purchaser, the purchaser suitably completes the purchaser 

15 transaction review page (step 1706) by providing information regarding the purchaser's 
card to effect a suitable transfer of funds from the purchaser's card account to the 
financial account of the seller. As illustrated in exemplary purchaser transaction review 
page 1800 of FIG. 18, the purchaser enters the appropriate information which may be 
requested by various transaction datafields provided by the transaction mechanism on 

20 the purchaser transaction review page 1800. The transaction datafields provided by 
the purchaser transaction review page may include suitable datafields of any number ~ 
or form, such as, for example, a datafield 1802 for the purchaser's name as it appears * 
on the card; a datafield 1804 for indicating a card account number; a datafield 1806 for ^ 
providing a card identification number, such ^as thd^four digits that are frequently 

25 printed on the card above the card number; and datafields 1808 for indicating the 
card's expiration date. 

Additionally, purchaser transaction review page 1800 may include any number 
or form of additional tabs or datafields. The additional tabs or datafields may be used 
by the purchaser to implement any suitable function which may further facilitate the 

30 transaction between the seller and the purchaser. For example, purchaser transaction 
review page 1800 may also include an additional datafield, or tab for accessing an 
additional datafield, which may permit the purchaser to provide or modify information 
regarding an escrow release event Such escrow release event information may 
include a particular time period within which a purchaser may either accept or reject 
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any it ms prior to the transfer ot Hinds trom tn scrow account to tne sellers account, 
such as a particular number of days after th purchaser receives goods, s rvices, or 
other value from a suitabl shipping agent If a purchaser modifies or adds information 
to th purchaser transaction review page, such as modifying or adding information 
regarding an escrow release event, the transaction flow as described herein preferably 
includes an additional communication or transmission- of the transaction terms to the 
seller so that the seller is given a suitable opportunity to either accept or decline the 
modified terms and conditions of the transaction. 

After the purchaser has suitably entered the requested -information,- the--- 

purchaser suitably submits the purchaser transaction review page to the transaction 
mechanism, such as by activating tab 1810 or pressing the enter key on a suitable 
input device for example. Once the purchaser's card information profile has been 
completed and the purchaser transaction review page is submitted, the transaction 
mechanism displays a suitable transaction invoice, such as exemplary purchaser 
transaction invoice 1900 of FIGS. 19A and 19B. At this point, the purchaser may 
ither accept or decline the transaction (step 1712). If the purchaser declines the 
transaction, such as by suitably activating tab 1902 of exemplary purchaser transaction 
invoice 1900, a suitable interface is displayed (step 1714), such as exemplary 
purchaser decline transaction page 2000 of FIG. 20, which may provide any suitable 
information or means for acquiring information, such as tabs 2002 and 2004. 

If the purchaser accepts the transaction, the transaction mechanism performs a 
suitable card authorization / authentication routine, which may include suitable credit 
risk and fraud risk analyses (step 1716). If the transaction is unacceptable, either due 
to a potential fraud risk or a credit risk, the ^transaction mechanism cancels the 
transaction and suitably notifies, such as by email, both the purchaser and the seller 
(step 1718). If the transaction is acceptable, the transaction mechanism suitably debits 
the purchaser's account Preferably, the transaction mechanism then credits an 
appropriate escrow account (step 1720), pending notification by either the purchaser 
and/or a shipping agent that any defined escrow release event has transpired (step 
1722). If the defined escrow release event transpires, the transaction mechanism 
suitably disburses the appropriate funds to the seller's financial account (step 1726) 
and notifies both the purchaser and the seller that the transaction has been completed 
(step 1728). However, if an escrow release event has been defined during the 
transaction by ither the transacting parties or a suitabl third party and th screw 
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release vent is not satisfied, the transaction mecnanism itner reverses tne 
transaction, such as by performing a suitable chargeback or som other suitabl 
transaction reversal procedure, or follows a suitable disput resolution protocol, as 
described abov (step 1724). As illustrated in phantom lines in ord r to represent 
5 alternative process flows, if any dispute between the parties is favorably resolved, 
suitable funds may be disbursed to the seller (step 1726) and the parties may be 
notified of the completion of the transaction (step 1728), However, if any dispute is not 
favorably resolved, or if the most appropriate resolution is cancellation of the 

transaction, the transaction. J& suitably terminated or otherwise reversed, and. the„. 

10 purchaser and seller are suitably notified of the termination and/or reversal of the 
transaction (step 1728). 

In the second case, the purchaser accepts the transaction by logging into the 
transaction system and selecting the option of transferring funds to the seller from the 
purchaser's card (step 1708). Alternatively, the purchaser accepts the transaction by 

15 logging into the transaction system and selecting the option of transferring funds to the 
seller from the purchaser's DDA (step 1710). In either of these situations, the 
transaction mechanism suitably processes the purchaser's login request and 
determines whether the purchaser is a registered user (step 1730). If the purchaser is 
not a registered user, the transaction mechanism provides a suitable registration 

20 interface (step 1732), such as described above with reference to FIG. 10. If the 
purchaser is a registered user, the transaction mechanism then performs steps 1712 
through 1728, as described above. 

Although the foregoing describes an exemplary seller-initiated transaction, one v 
skilled in the art will appreciate that the present inventioads not so limited and may be 

25 readily implemented by means of any suitable purchaser-initiated transaction or, 
alternatively, any suitable third-party-initiated transaction, such as an intermediary- 
initiated transaction. 

Exemplary Transaction Mechanism 
30 As one skilled in the art will appreciate, the transaction mechanism of the 

present invention may be suitably configured in any of several ways. It should be 
understood that the transaction mechanism described herein with reference to FIG. 21 
is but one exemplary embodiment of the invention and is not intended to limit the 
scope of the invention as described above. FIG. 21 illustrates an exemplary 
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transaction mechanism 2100 comprising a C2C Service 2104; a Transaction Manager 
2106; a Business Rul s Engine 2108; an Express Net Interface Manager 2110; an 
eMailers Engine 2112; an SSL Gateway Interface Manager 2114; a C2C Logging 
Engine 2116; and a Financial Transaction Submission Daemon 2118. 
5 The C2C Service 2104 suitably processes initial transaction requests from 

Internet users 2102. Exemplary processes performed by the C2C Service 2104 
include requesting transaction information, such as card and/or DDA information, from 
an Internet user 2102 who has logged into the transaction system; validating the data 
entered by an Internet user 2102; and submitting a completed transaction invoice to 

10 the Transaction Manager 2106. The C2C Service 2104 communicates with the other 
components of the system through any suitable communications link, including a 
network connection such as an Intranet, extranet, and/or the like. 

The Transaction Manager 2106 performs a variety of processes which facilitate 
a transaction between a seller and a purchaser. These processes may include 

15 creating transaction invoices and managing them, including updating a particular 
transaction invoice at the various stages of the transaction process; sending emails to 
sellers and purchasers using the E-Mailers Engine 2112; and processing requests from 
the Virtual Point of Sale (VPOS) Capture Daemon for transactions which are eligible 
for submission to the financial capture systems, as described in greater detail below. 

20 The Business Rules Engine 2108 preferably provides access to a variety of 

operating standards that may be applied to any given transaction between a seller and 
a purchaser. The applicable operating standards may include, but are not limited to, 
any of the following: (1) given a transaction type and a transaction, Business Rules 
Engine 2108 may return a suitable pricing modefto be^applied to the transaction; (2) 

25 Business Rules Engine 2108 may compute a transaction fee based upon a certain 
number of basis points, which preferably is a configurable parameter generated from a 
suitable fee table (for example, one basis point = .01%, so 375 bp = 3.75% of the total 
price of the transaction); (3) Business Rules Engine 2108 may apply a flat transaction 
fee; and/or (4) given a transaction and a transaction type, Business Rules Engine 2108 

30 may apply a fraud model to the transaction, wherein the exemplary fraud model may 
include any of the following: (a) authorization for the purchaser's part in the 
transaction, including billing address verification and 4DBC verification of the 
purchaser; (b) verification of a lack of any relationship between the purchaser and the 
seller, wherein all transactions showing a relationship (such as "self or other personal 
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relationship) between the purchaser and the seller may b tailed" or otherwise 
terminat d; (c) application of a 3-strike rule, wherein th transaction is failed or 
terminated if a 3 rd attempt to authorize the transaction fails and an mail is sent to the 
seller providing an explanation for th cancellation of the transaction; and (d) 
5 v rification that the transaction amount has not exceeded any prescribed limits, such 
as a limit on the transaction amount and/or a limit regarding the maximum number of 
transactions that may be conducted between a first party and any other party during 
some defined period of time (such as per day, per week, per month, etc.)- Preferably, 
- -any- applicable -transaction limits are provided as configurable ^^.pacameteis by the . „ _ 

1 0 Business Rules Engine 2108. 

In the case of both verification of the purchaser's billing address and verification 
of purchaser/seller non-relationship, a 'system not available' response is possible, in 
which case the Business Rules Engine 2108 may recommend either a time-out or that 
the transaction be terminated. 

15 Preferably, the non-relationship verification is the first process sent to the credit 

authorizations system (CAS) from the transaction mechanism 2100, since the data for 
this process preferably is contained within the CAS rather than a separate cardmember 
system (IMS, Triumph). The CAS is an online system which analyzes charge requests 
and either approves the charge requests or refers them to an Authorizer for a decision. 

20 CAS preferably contains a negative file, a delinquency file, and an accumulative file. If 
the purchaser and seller pass the non-relationship verification, then an authorization v 
request (with AAV and 4DBC) is sent. The authorization request preferably involves ^ 
CAS accessing a suitable cardmember system to verify the billing address. .> 
The Express Net Interface Manager 2110 communicates with the Express Net, 

25 the utility which processes user registration and manages the accounts of registered 
users. The Express Net Interface Manager 2110 accesses the Express Net and 
acquires any suitable user data which may be desired to process a particular pending 
transactioa Preferably, the Express Net Interface Manager 2110 acquires a list of the 
Internet user's registered cards and/or DDAs as well as other unique data pertaining to 

30 the Internet user 2102, wherein the exemplary information may be used to process the 
transaction. 

The eMailers Engine 2112 preferably sends suitable email notifications and/or 
confirmations to both the seller and the purchaser in the case of either a merchandise 
transaction or a transfer of funds. For example, the eMailers Engine 2112 may send 
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an mail comprising a notification which may: (1 ) notify a purchaser, preferably with an 

ncrypt d URL, of a transaction or funds transfer initiated by a seller and provid 
suitable means for the purchaser either to accept r decline the transaction or funds 
transfer; (2) copy th seller on the notification sent to th purchaser, and/or (3) indicate 
5 to both a seller and a purchaser that the purchaser has either accepted or declined a 
transaction or transfer of funds. 

The SSL Gateway Interface Manager 2114 preferably communicates with the 
SSL Gateway, which preferably includes a Payment Gateway Client Class and a CAS 
Authentication Component. The SSL Gateway is a message and. file distribution „ 

10 system which accepts authorization requests online and distributes those authorization 
requests to the proper authorization system. The Payment Gateway Client Class 
preferably processes all of the protocol and transport level responsibilities that are may 
be used for communicating with the Payment Gateway Server, which operates as a 
part of the SSL Gateway. Preferably, the defined protocols include the addition of a 

15 MIME header to all XML messages sent to the payment gateway and the use of 
TCP/IP sockets for communication with the Payment Gateway. The CAS 
Authentication Component preferably is responsible for performing the CAS financial 
authorization processes (IS08583) as well as performing the CAS non-relationship 
v rification processes based upon the new ISO message. 

20 The C2C Logging Engine 21 16 preferably audits and error logs all events in the 

transaction system 2100. Preferably, the C2C Logging Engine 21 16 logs errors in the . 
transaction system 2100 into a flat file. Preferably, the CA Unicenter agent for * 
production support uses this flat file. 

The Financial Transaction Submission Daemon preferably submits each 

25 transaction's financial transaction record, such as a credit and/or debit Virtual Point of 
Sale (VPOS) record that results from a particular card to card or card to DDA 
transaction, to a VPOS Acceptance System 2202 via the SSL Gateway 2204, as better 
seen in FIG. 22. Preferably, each individual financial transaction record is submitted to 
the VPOS Acceptance System as it is received, without being processed as part of a 

30 batch file. The VPOS Acceptance System receives the financial transaction record, 
formats the financial capture file, and forwards the financial capture file to the SSL 
Gateway. The SSL Gateway then forwards the financial capture file to the appropriate 
financial capture system. The submission of the financial transaction record preferably 
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is based upon a message-based protocol that is implemented by the VPOS 
Acceptance System. 

Although th inv ntion has been d scribed herein as facilitating comm rcial 
transactions between parties r siding at remote locations, one of ordinary skill in th 
5 art will appreciate that the invention is not so limited and includes the facilitation of 
commercial transactions between co-located parties. 

It should be understood, however, that the detailed description and specific 
examples, while indicating exemplary embodiments of the present invention, are given 
for purposes of illustration only-arid- not of limitation. Many changes and modifications 

10 within the scope of the instant invention may be made without departing from the spirit 
thereof, and the invention includes all such modifications. The corresponding 
structures, materials, acts, and equivalents of all elements in the claims below are 
intended to include any structure, material, or acts for performing the functions in 
combination with other claimed elements as specifically claimed. The scope of the 

15 invention should be determined by the appended claims and their legal equivalents, 
rather than by the examples given above. For example, the steps recited in any 
method claims may be executed in any order and are not limited to the order 
presented in the claims. Moreover, no element is essential to the practice of the 
invention unless specifically described herein as "critical" or "essentiar. 
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What is claimed is: 

1. A method of facilitating comm rcial transactions, which m thod 

comprises the steps of: 

registering at least one of a first party and a second party with a 

transaction mechanism; 

receiving from at least one of said first party and said second party a 
request -to debit a financial account of said first party to effectuate a transaction 
between said first party and said second party; 

receiving from at least one of said first party and said second party 
transaction information relating to said transaction between said first party and said 
second party; 

determining whether said transaction is acceptable based upon at least 
one of said transaction information and said request to debit said financial account 
associated with said first party; 

debiting funds from said financial account of said first party; 

disbursing said funds to a financial account associated with said second 

party; and 

crediting said funds to said financial account associated with said second 

party. 

2. The method of claim 1 t wherein the step of debiting funds from said 
financial account of said first party further comprises ffolding "said funds in an escrow 
account until an escrow release event has transpired, and wherein the method further 
comprises the step of releasing said funds from said escrow account prior to the step 
of disbursing said funds to a financial account associated with said second party. 

3. The method of claim 2, wherein holding said funds in an escrow account 
until an escrow release event has transpired comprises holding said funds in an 

screw account until an occurrence of at least one of a receipt by said first party of 
goods, services, or other value from said second party and a lapse of a predefined 
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period of time within which said first party may evaiuat said goods, services, or other 
valu from said second party. 

4. The method of claim 1, wh rein receiving from at least on of said first 
5 party and said second party a request to debit a financial account associated with said 
first party comprises receiving a request to debit a financial account associated with 
said first party selected from the group consisting of a transaction card account, a 
demand deposit account, a credit line, and a money market account. 

10 5. The method of claim 1, wherein disbursing said funds to a financial 

account associated with said second party comprises disbursing said funds to a 
financial account associated with said second party selected from the group consisting 
of a transaction card account, a demand deposit account, a credit line, a digital cash 
account, and a money market account. 

15 

6. The method of claim 1, wherein registering at least one of said first party 
and said second party comprises providing said transaction mechanism with a financial 
account identifier for identifying a financial account associated with said first party. 

20 7. The method of claim 6, wherein providing said transaction mechanism 

with a financial account identifier for identifying a financial account associated with said v 
first party comprises providing a financial account identifier selected from the group v 
consisting of a card number and a demand deposit account number. 

25 8. The method of claim 1 , wherein registering at least one of said first party 

and said second party comprises providing said transaction mechanism with a financial 
account identifier for identifying a financial account associated with said second party. 

9. The method of claim 8, wherein providing said transaction mechanism 
30 with a financial account identifier for identifying a financial account associated with said 
second party comprises providing a financial account identifier selected from the group 
consisting of a card number and a demand deposit account number. 
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10. The m mod ot claim 1 , wherein receiving transaction information relating 
to said transaction from at I ast one of said first party and said second party comprises 
at least one of receiving a financial account identifier associated with the financial 
account associat d with said first party and receiving a financial account identifier 

5 associated with said financial account ass. dated with said second party. 

11. The method of claim 1, wherein determining whether said transaction is 
acceptable further comprises performing at least one of a credit risk analysis and a 
fraud risk analysis, and wherein^sajd transaction is deemed unacceptable rf a potential 

1 0 risk associated with said transaction is unacceptable. 

12. The method of claim 1 , further comprising receiving a request for a value- 
added service from at least one of said first party and said second party. 

15 13. The method of claim 12, wherein receiving a request for a value-added 

service comprises receiving a request for a value-added service selected from the 
group consisting of insurance, dispute resolution, and postal tracking. 

14. The method of claim 13, wherein receiving a request for a value-added 
20 service comprises receiving a request for dispute resolution and wherein the method 

further comprises the step of providing a dispute resolution mechanism to mediate a 
dispute concerning said transaction between said first party and said second party. 

15. The method of claim 1, further comprising the step of receiving 
25 notification that said first party has received goods, services, or other value shipped 

from said second party to said first party. 



16. The method of claim 1, further comprising the step of providing an 
intermediary to facilitate said transaction between said first party and said second 

30 party. 

17. The method of claim 16, wherein the step of providing an intermediary 
further comprises providing an intermediary selected from the group consisting of an 
online auction, an online classified ad site, and an online merchant 
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18. Th method of claim 1, furth r comprising the step of providing a 
shipping agent to ship goods, services, or other valu from said second party to said 
first party. 

5 

19. The method of claim 18, wherein the step of providing a shipping agent 
further comprises maintaining by said transaction mechanism at least one of said first 
party's and said second party's identity and address in confidence with respect to 

ither said first or said second party. . 

10 

20. A system for transferring financial tender from a financial account 
associated with a first party to a financial account associated with a second party, 
which system comprises: 

a transaction mechanism; 
15 a first party in communication with said transaction mechanism; 

a second party in communication with said transaction mechanism; 

wherein at least one of said first party and said second party registers 
with said transaction mechanism to provide said transaction mechanism with at least 
one financial account identifier to identify at least one financial account associated with 
20 at least one of said first party and said second party; 

wherein said transaction mechanism is in communication with a financial 
account associated with said first party and a financial account associated with said - 
s cond party; and 

wherein, in response to a transaction request from at least one of said 
25 first party and said second party, said transaction mechanism debits funds from a 
financial account associated with said first party and disburses said funds to a financial 
account associated with said second party. 

21. The system of claim 20, wherein in response to a transaction request 
30 from at least one of said first party and said second party, said transaction mechanism 

debits funds from a financial account associated with said first party, holds said funds 
in an escrow account until an escrow release event has transpired, releases said funds 
from said escrow account, and then disburses said funds to a financial account 
associated with said second party. 
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22 The system of claim 21 , wh r in said escrow release ev nt compris s at 
least on of receipt by a purchaser of goods, services, or oth r valu from a seller and 
th lapse of a predefined period of time within which said purchaser may evaluate said 
5 goods, services, or other value. 

23. The system of claim 20, wherein said financial account associated with 
said first party is selected from the group consisting of a transaction card account, a 
demand deposit account, a credit line, and a money market account 

10 

24. The system of claim 20, wherein said financial account associated with 
said second party is selected from the group consisting of a transaction card account, 
a demand deposit account, a credit line, and digital cash account, and a money market 
account. 

15 

25. The system of claim 20, wherein said transaction request includes 
transaction information relating to a transfer of funds between said first party and said 
second party, and wherein said transaction mechanism authenticates at least one of 
said first party and said second party based upon said transaction information 

20 

26. The system of daim 20, wherein said transaction request includes 
transaction information relating to a transfer of funds between said first party and said * 
second party, and wherein said transaction mechanism performs at least one of a -* 
credit risk analysis and a fraud risk analysts to determines potential risk associated 

25 with said transaction. 

27. The system of claim 26, wherein said transaction mechanism comprises 
customer transaction records related to said financial account associated with said first 
party, and wherein said transaction mechanism evaluates said customer transaction 

30 records to determine a risk of fraud associated with said transaction request 

28. The system of claim 20, further comprising an intermediary in 
communication with at least one of said transaction mechanism, said first party, and 
second party. 
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29. The system of claim 28, wherein said int rmediary is selected from the 
group consisting of an online auction, an online classified ad sit , and an onlin 
merchant 

5 

30. The system of claim 20, further comprising a shipping agent in 
communication with at least one of said transaction mechanism, said first party, and 
said second party. 

10 31. The system of claim 20, wherein said transaction mechanism performs a 

value-added service in conjunction with processing said transaction request. 

32. The system of claim 31, wherein said value-added service is selected 
from the group consisting of insurance, postal tracking, and dispute resolutioa 

15 

33. A computer-readable storage medium encoded with processing 
instructions for implementing a method performed by a transaction mechanism for 
transferring financial tender from a financial account associated with a first party to a 
financial account associated with a second party, said processing instructions directing 

20 a computer to perform the steps of. 

registering at least one of a first party and a second party with a 
transaction mechanism; 

receiving from at least one of said first party and said second party a, 
request to debit a financial account associated with saicMirst party to effectuate a 
25 transaction between said first party and said second party; 

receiving from at least one of said first party and said second party 
transaction information relating to said transaction between said first party and said 
second party; 

determining whether said transaction is acceptable based upon at least 
30 one of said transaction information and said request to debit said financial account 
associated with said first party; 

debiting funds from said financial account associated with said first party, 
disbursing said funds to a financial account associated with said second 

party; and 
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crediting said funds to said financial account associated with said second 

party. 



34. The computer-readable storag medium of claim 33, wherein th step of 
5 d biting funds from said financial account of said first party further comprises holding 

said funds in an escrow account until an escrow release event has transpired, and 
wherein said processing instructions further direct a computer to perform the step of 
releasing said funds from said escrow account prior to the step of disbursing said funds 
to a financial account associated with said second party. 

10 

35. The computer-readable storage medium of claim 34, wherein the step of 
holding said funds in an escrow account until an escrow release event has transpired 
comprises holding said funds in an escrow account until an occurrence of at least one 
of receipt by said first party of goods, services, or other value from said second party 

15 and a lapse of a predefined period of time within which said first party may evaluate 
said goods, services, or other value from said second party. 

36. The computer-readable storage medium of claim 33, wherein the step of 
receiving from at least one of said first party and said second party a request to debit a 

20 financial account associated with said first party further comprises receiving a request 
to debit a financial account associated with said first party selected from the group 
, consisting of a transaction card account, a demand deposit account, a credit line, a 
digital cash account, and a money market account 

25 37. The computer-readable storage medium of claim 33, wherein the step of 

disbursing said funds to a financial account associated with said second party 
comprises disbursing said funds to a financial account associated with said second 
party selected from the group consisting of a transaction card account a demand 
deposit account, a credit line, and a money market account. 

30 

38. The computer-readable storage medium of claim 33, wherein the step of 
registering at least one of said first party and said second party comprises providing 
said transaction mechanism with a financial account identifier for identifying a financial 
account associated with said first party. 
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39. Th computer-readable storage medium of claim 38, wh rein the step of 
providing said transaction mechanism with a financial account identifier for identifying a 
financial account associated with said first party comprises providing a financial 

5 account identifier selected from the group consisting of a card number and a demand 
deposit account number. 

40. The computer-readable storage medium of claim 33, wherein the step of 
registering at least one of said first party and said second party comprises providing 

10 said transaction mechanism with a financial account identifier for identifying a financial 
account associated with said second party. 

41 . The computer-readable storage medium of claim 40, wherein the step of 
providing said transaction mechanism with a financial account identifier for identifying a 

15 financial account associated with said second party comprises providing a financial 
account identifier selected from the group consisting of a card number and a demand 
deposit account number. 

42. The computer-readable storage medium of claim 33, wherein the step of 
20 receiving transaction information relating to said transaction from at least one of said 

first party and said second party comprises at least one of receiving a financial account „ 
identifier associated with the financial account associated with said first party and . 
receiving a financial account identifier associated with said financial account * 
associated with said second party. 

25 

43. The computer-readable storage medium of claim 33, wherein the step of 
determining whether said transaction is acceptable further comprises performing at 
least one of a credit risk analysis and a fraud risk analysis, and wherein said 
transaction is deemed unacceptable "if a potential risk is associated with said 

30 transaction. 



44. The computer-readable storage medium of claim 33, further comprising 
the step of receiving a request for a value- added service from at least one of said first 
party and said second party. 
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45. The cornputer-readabl storage medium of claim 44, wherein th step of 
receiving a request for a value-added s rvice comprises receiving a request for a 
value-added service sel cted from th group consisting of insurance, dispute 

5 resolution, and postal tracking. 

46. The computer-readable storage medium of claim 45, wherein the step of 
receiving a request for a value-added service comprises receiving a request for dispute 
resolution and wherein the method further comprises the step of providing a dispute - 

10 resolution mechanism to mediate a dispute concerning said transaction between said 
first party and said second party. 

47. The computer-readable storage medium of claim 33, further comprising 
the step of receiving notification that said first party has received goods, services, or 

15 other value shipped from said second party to said first party. 



20 



25 



48. The computer-readable storage medium of claim 33, further comprising 
the step of providing an intermediary to facilitate said transaction between said first 
party and said second party. 

49. The computer-readable storage medium of claim 48, wherein the step of ^ 
providing an intermediary further comprises providing an intermediary selected from > 
the group consisting of an online auction, an online classified ad site, and an online 
merchant — ^ 

50. The computer-readable storage medium of claim 33, further comprising 
the step of providing a shipping agent to ship goods, services, or other value from said 
second party to said first party. 



30 51. The computer-readable storage medium of claim 50, wherein the step of 

providing a shipping agent further comprises maintaining by said transaction 
mechanism at least one of said first party's and said second party's identity and 
address in confidence with respect to either said first party or said second party. 



50 



WO 01733522 



PCT/USOO/30483 



52. Ad vice for transferring financial tender from a financial account 
associated with a first party to a financial account associated with a second party, 
which device comprises: 

a central processor; 

5 a storage device in communication with said central processor via a 

system bus; 

a memory connected to said central processor, wherein said memory 
includes an operating system for storing and executing a program which controls 

operation of said central processor;- — - 

10 wherein said central processor is operative with a transaction mechanism 

to: 

register at least one of a first party and a second party with said 
transaction mechanism; 

receive from at least one of said first party and said second party a 
15 request to debit a financial account associated with said first party to effectuate a 
transaction between said first party and said second party; 

receive from at least one of said first party and said second party 
transaction information relating to said transaction; 

determine whether said transaction is acceptable based upon at 
20 least one of said transaction information and said request to debit said financial 
account associated with said first party; 

debit funds from said financial account associated with said first > 

party; and 

disburse said funds to a financial account associated with said 

25 s cond party. 

53. the device of claim 52, wherein said central processor further is 
operative with a transaction mechanism to hold said funds in an escrow account until 
an escrow release event has transpired and to release said funds from said escrow 

30 account prior to disbursing said funds to a financial account associated with said 
second party. 

54. The device of claim 52, further comprising a network interface in 
communication with said central processor via a system bus. 
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55. Th device of claim 52, wherein said storag device compris s a 
customer transaction records database and a customer information r cords database. 

5 56. The device of claim 52 wh rein said m mory comprises a risk 

management module, a transaction control module, and an authentication module. 

57. The device of claim 52, wherein said financial account associated with 
said first party is selected from the group consisting of a transaction card account, a 

10 demand deposit account^ a credit line, a digital cash account, end a money market 
account. 

58. The device of claim 52, wherein said financial account associated with 
said second party is selected from the group consisting of a transaction card account, 

15 a demand deposit account, a credit line, and a money market account. 

59. A method of processing a plurality of commercial transactions, which 
method comprises the steps of: 

receiving a plurality of requests to debit a plurality of financial accounts; 
20 creating a financial transaction record for each of said plurality of 

requests; and 

submitting each financial transaction record individually to an acceptance 

system. 

25 60. The method of claim 59, further comprising the step of formatting a 

financial capture file and forwarding said financial capture file to a financial capture 
system. 



52 



PCT/US00/3O483 



1/23 




SELLER 



1. BUYER AND SELLER AGREE ON 
TERMS 



2. BUYER MAILS CHECK OR 
MONEY ORDER TO SELLER 



3. SELLER DEPOSITS CHECK IN 
BANK 



$$$ 



4.BANK APPROVES CHECK, CHECK 
CLEARS 




SELLER 



5. SELLER SHIPS GOODS 

6. BUYER RECEIVES GOODS 

ELAPSED TIME: 2-3 WEEKS UNTIL 
SELLER RECIVES "GOOD FUNDS", 
3-4 WEEKS UNTIL BUYER 
RECEIVES GOODS 



(PRIOR ART) 

FIG.1 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/US00/30483 



2/23 




FIG.2 



SUBSTITUTE SHEET (RULE 26) 



WO 01733522 



PCT/US00/30483 




FIG.3 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/US00/30483 



4/23 



PURCHASER 



410 



416 



SHIPPING 
AGENT 




INTERMEDIARY 



TRANSACTION 
MECHANISM 



PURCHASER'S 
FINANCIAL 
INSTITUTION 




400 




406 



SELLER 



408 



SELLER'S 
FINANCIAL 
INSTITUTION 



FIG.4 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/USOO/30483 



5/23 



,502 



TRANSACTION MECHANISM 
,510 



504 



CENTRAL 
PROCESSOR 



^1 



MEMORY 



PI3K 

MANAGEMENT 
MODULE 

> — 514 



TRANSACTION 
CONTROL 
MODULE 

^ — 512 



AUTHENTICATION 
MODULE 



516 



OPERATING SYSTEM 



7 



506 



518 



508 



DISPLAY DEVICE/ 
INPUT DEVICE 



1 



522 



STORAGE DEVICE 



CUSTOMERS' 
TRANSACTION 
RECORDS 



524 



CUSTOMERS' 
INFORMATION 
RECORDS 



526 



L 



520 



NETWORK 
INTERFACE 



FIG.5 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/USOO/30483 



6/23 



(start) 



PURCHASER REGISTERS WITH TRANSACTION 
MECHANISM 



SELLER REGISTERS WITH TRANSACTION MECHANISM 



PURCHASER AND SELLER AGREE UPON TRANSACTION 

TERMS 



T 



PURCHASER SELECTS METHOD FOR TRANSFERRING 
FUNDS TO SELLER AND, IF AVAILABLE, SELECTS VALUE- 
ADDED SERVICES 



PURCHASER/SELLER PROVIDE TRANSACTION 
INFORMATION TO TRANSACTION MECHANISM FOR 
AUTHENTICATION AND/OR FRAUD ANALYSIS 



FRAUD 
ANALYSIS 



CREDIT 
ANALYSIS 




TRANSACTION MECHANISM 
DEBITS PURCHASER'S 
FINANCIAL ACCOUNT 



616 



602 
604 

606 

608 
610 



TRANSACTION MECHANISM HOLDS FUNDS IN ESCROW 
ACCOUNT 



V 



618 



TRANSACTION MECHANISM RELEASES FUNDS FROM \j 
ESCROW AND DISBURSES TO SELLER'S FINANCIAL 
ACCOUNT 



620 



,622 



SELLER'S FINANCIAL INSTITUTION CREDITS SELLER'S 
FINANCIAL ACCOUNT 



<jmT) 



FIG.6 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/USOO/30483 



7/23 



(start) 
_3 



RECEIVE PURCHASER REGISTRATION INFORMATION, 
INCLUDING FINANCIAL ACCOUNT INFORMATION 



RECEIVE SELLER REGISTRATION INFORMATION, 
INCLUDING FINANCIAL ACCOUNT INFORMATION 



OPTIONALLY RECEIVE INDICATION OF INITIATION OF 
TRANSACTION BETWEEN PURCHASER AND SELLER 



.RECEIVE PURCHASER'S SELECTION OF METHOD FOR 
TRANSFERRING FUNDS TO SELLER AND, IF AVAILABLE, 
SELECTION OF VALUE-ADDED SERVICES 



RECEIVE TRANSACTION INFORMATION FROM 
PURCHASER/SELLER FOR AUTHENTICATION AND/OR 
FRAUD DETECTION 



FRAUD 
ANALYSIS 



CREDIT 
ANALYSIS 




DEBIT PURCHASER'S 
FINANCIAL ACCOUNT 



716 



702 
704 

706 

708 
710 



HOLD FUNDS IN ESCROW ACCOUNT 



V 



I 



718 



RECEIVE INFORMATION REGARDING ESCROW 
RELEASE EVENT 



1/ 



720 



RELEASE FUNDS FROM ESCROW ACCOUNT AND 
DISBURSE TO SELLER'S FINANCIAL ACCOUNT 



722 



FIG.7 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/USOO/30483 



8/23 




SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/USOO/30483 



9/23 




CUSTOMER SERVICE 



FIG.9 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/US00/30483 



10/23 



JCOHSUMER TO CONSUMER-MICROSOFT INTERNET EXPLORER" 
FILE EDIT VIEW GO FAVORITES HELP 



OSS 



O □ d Q Q O ^8 63 © & 
BACK FORWARD STOP REFRESH HOME SEARCH FAVORITES HISTORY CHANNELS FULLSCREEN HAIL PRINT 



ADBreSfTffifHTMECI^ 



□ UKK> 



AMERICAN 
EXPRESS 



2/23/00 

CONSUMER TO CONSUMER 
FLOW CHART 
DOWNLOAD ZIP 
CONTENT PAGES 
♦C.2C-M C2C MAIN PAGE 

■C2C-1 C2C BENEFITS & INFORMATION PAGE < 
•TC R TERMS AND CONDITIONS FOR REGISTERING ^ 
SELLER FLOW 
■TM TRANSACTION MANAGER 
•H1 HELP AND FAQS ISELLERt 
»TC TERMS ANb CONDITIONS FOR SELLERS 
•H-1 ARCHIVED LIST INVOICES 
■H-2 INVOICE DETAIL 
-NI-1 SELLER NEW INVOICE 
•Nl-I-C SELLER CANCELS ORDER PAGE 
♦NM-E SELLER NEW INVOICE ERROR 
»N 1-2 CONFIRM. EDIT. OR CANCEL ORDER 
•NI-2THX SELLER THANK YOU 



1002 



HTERNET20NE 



FIG.10 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/USOO/30483 



11/23 



g AMERICAN EXPRESS-MICROSOFT INTERNET EXPLORER 



BBS 



E1LE EDIT ttlEW 60 FAVORITESIELP 



o o d q C3 o v a © s 

BACK FORWARD STOP REFRESH HOME SEARCH FAVORITES HISTORY CHANNELS FULLSCREEN HAIL PRINT 



ADDRESSQiTTPirRIBECA.Sl6.6SH.C0y/CONSUHER TO C0KSUMERJBUILD/C2C M-ASP" 



T^l UNK> 



ITEMS / PERSONAL \° SMALL BUSINESS °C0RPORATI0NS \ 



AMERICAN 
EXPRESS 



►CARDS 



eJRAXEI afntfrtainmfnt 

i> FINANCIAL SERVICES 



> EXPRESS SHOPPER 



WELCOME TO AMERICAN EXPRESS 
CONSUMER TO CONSUMER 
PAYMENTS 

BUYING AND SELLING ONLINE 
JUST GOT EASIER 

WITH CONSUMER TO CONSUMER PAYMENTS. AMERICAN 
EXPRESS BRINGS CARDMEMBERS A QUICK AND CONVENIENT 
WAY TO CONDUCT ONLINE SALES AND PURCHASES WITH EACH 
OTHER. BUYERS CAN MAKE FAST PAYMENTS. AND SELLERS 
HAVE AN EASY WAY TO ACCEPT PAYMENT FOR THEIR GOODS. 

. CIICKHFRFTOLOG IN TO AMERICAN EXPRESS ONLINE SERVICES 
AND ACCESS THE CUSTOMER TO CUSTOMER PAYMENTS PROGRAM. 



^NOAI 
1102 



PAY IN FULL 

OR PAY OVER TIME. 

CDCK HERE TO L£ARN HORE 
REGISTER 
^ TODAY 



COPYRIGHT®2000 AUERJCAN EXPRESS COMPANY All RIGHTS RESERVED.USERSOFTHiS SITE AGREE TO BE KfUND BY THE TERUS OF THE AMERICAN EXPRESS WEE SITE RULES AND 
REGULATSQNS.YIFJ WEB SiTE RULES AND REGULATIONS AND TRADEMARKS AND PRIVACY STATEMENT OF AHERiCAN EXPRESS 



•NTERNETZONE 



nPOWNLOADING PICTURE HTTPjfTRBECASlD jSHCOttCONSUHER TO CCNSUMERJBUlDflMAGESKLEARCT" 



l5sTtft1IS)M 



FIG.11 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/US00/3O483 



12/23 



@ AMERICAN EXPRESS-MICROSOFT INTERNET EXPLORER 



QBE 



FILE EDIT VIEW GO FAVORITES HELP 



o d d ql cj o ^ a@d 

BACK FORWARD STOP REFRESH HOME SEARCH FAVORITES HISTORY CHANNELS FULLSCREEN MAIL PRINT 



ADDRESSpFrTFFRIBECA.SIG.BSHXOMCOKSUMER_tO_C0MSUMERffiJlLb/rMJ^P 



UM> 



AMERICAN 
EXPRESS 



mm 



PERSONAL \° SMALL BUSINESS °CORPORATtONST 



^AW 



TRAVEL i 
ENTERTAINMENT 
FINANCIAL PLANNING & 
INVESTING 



EXPRESS SHOPPER 



CONSUMER TO CONSUMER PAYMENTS 
WELCOME JOHN A. SAMPLE ^1202 
ST ART A NEW TRANSACATION \ ^ 



ISTATUS KEY 



YOUR TRANSACTION HISTORY: 



1204 



P=PAID 

W=WAITING ON BUYER 
D=DECLINED BY BUYER 
E=EXPIRED 



EXIT SECURE AREA 



INV# BUYER x REF# DESCRIPTION CREATED TOTAL 


STATUS 


0:300925 TINCIDUNT@YAHOO.COM 4562 BLUE VASE 


2/23/00 


$200.00 


P 


0:300925 TINCIDUNT0YAHOO.COM 4562 BLUE VASE 


2/23/00 


$200.00 


P 


0:300925 TINCIDUNT6YAHO0.COM 4562 BLUE VASE 


2/23/00 


S200.00 


P 


0:300925 TINCIDUNT@YAH00.COM 4562 BLUE VASE 


2/23/00 


$200.00 


P 



«BACK 1 2 345NEXT» 



CREDIT OPTIONS 



• TO REVIEW YOUR REGISTERED AMERICAN EXPRESS ONLINE ACCOUNTS CLICK HERE 
•TO REGISTER ANOTHER ACCOUNT CJJCKHERE v_ ^06 



1208 



IX-M1CR0 1 1 D YAHOO MAI I I DCAPEELLA UNK I f5[ E^MlM] iQAMERjCAp [DEXPLOBiMJ |5WfflCjCfLW^(Q^^^KDATAl fl 



1035UI *>■ 
J J 



FIG.12 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



13/23 



PCT/USOO/30483 



SELLER 
REGISTERS 



1306 



1 



1314 



CANCEL 
TRANSACTION 
PAGE 



1319 



FIG. 13 



SELLER-INITIATED TRANSACTION 



( START ^ 
z5_ 



SELLER REQUESTS TRANSACTION 




IS 

NO / SELLER 
.REGISTERED. 
USER 



1304 



TRANSACTION INVOICE ENTRY PAGE 
DISPLAYED 



SELLER COMPLETES TRANSACTION 
INVOICE ENTRY PAGE 



MAIN 


CANCEL. 


PAGE 





1302 




1308 



1310 



1316 



TRANSACTION INVOICE TRANSMITTED TO 
BOTH PURCHASER & SELLER 

T 



1320 



1322 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/US00/30483 



14/23 



15 — AMERICAN EXPRESS-MICROSOFT INTERNET EXPLORER 



EHB3 



FILE EDIT VIEW GO FAVORITES HELP 



CD 



o d c* <a d o ^8 a e a 

BACK FORWARD STOP REFRESH HOME SEARCH FAVORITES HISTORY CHANNELS FULLSCREEN HAIL PRINT 



ADDRESSiCTnTPiTRlBECASlG.BSH.COM/C0NSUMER TO C0NSUMERJBU1LDINMASP ' 



AMERICAN 
EXPRESS 



ITEMS / PERSONAL \°SMALL BUSINESS QCORPORATIONSX 



1400 



^CARDT 



TRAVEL & 
ENTERTAINMENT 



FINANCIAL PLANNING & 
INVESTING 



EXPRESS SHOPPER 



CONSUMER TO CONSUMER PAYMENTS 
START TRANSACTION 



1406 



1404 



ISTEP 41 CREATE INVOicT 



TO: I 



1402 



(BUYER'S EMAIL ADDRESS) 
FROM: JOHN.SAMPLE@HOTMAIL.COM 



DESCRIPTION 



INDICATE THE LAST DATE VOL 
WILL ACCEPT PAYMENT FOR ITEM(S): 

PROVIDE YOUR OWN REFERENCE NUMBER , IF ANY: 

PROVIDE INVOICE DESCRIPTION, I FANYj; 




QUANTITY PRICE /SUBTOTAT 



EXIT SECURE AREA 



] — ^1410 



j-x.1410 



NEED MORE LINE ITEMS? [ADjEK- 1426 
I CANCEL F t 1432 1 SUBMIT n - 1434 




1408 



\l414 
J 



INSURANCE 
SHIPPING & HANDLING 
OTHER 

TOTAL TO BE CHARGED TO BUYER 



1416 

S 

1416 



M418 
H420 
H422 
M424 



fSTEP 42 SELECT CREDIT OPTIONS 



1428 



PLEASE SELECT THE REGISTERED ACCONT TO WHICH YOU WOULD LIKE THE PROCEEDS 
OF THIS TRANSACTION CREDITED: 

1430 



'AMERICAN EXPRESS CARD 



mmmm 



□ DONE 



It 



1lE^B0X4llCR0ll □YAHOOTjAlLlI QCAPEEUA UNKll 0LEARNH6 SPAI I D AtERlCAN- 1 HZOPLORBtGI fOMICROSOFT W_. llatlVOICE If] 



I ill I Ml I 



I&38UI 



FIG.14 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/CSOO/30483 



« 

15/23 



□ AMERICAN EXPRESS-MICROSOFT INTERNET EXPLORER 




EILE EDIT VIEW GO FAVORITES HELP 




♦ -^ODi^QD O « H © d 
BACK FORWARD STOP REFRESH HOME SEARCH FAVORITES HISTORY CHANNELS FULLSCREEN HAH PRINT 


ADDRESSinHrtPfnM(^.&SH£OMCONSUMER^ 


|v|lMK> 



AMERICAN 
EXPRESS 



ITEMS / PERSONAL \°SMALL BUSINESS- °CORPORATIONS\ 



>CARDS 



TRAVELS 
ENTERTAINMENT 



FINANCIAL PLANNING 4 
INVESTING 



EXPRESS SHOPPER 



CONSUMER TO CONSUMER PAYMENTS 
VIEW INVOICES 
STEP 4 CREATE INVOICE 



TO: GL0RIAPU6LIC@YAHP0.COM 
FROM: J0HN_SAMPLE@H0TMAIL.COM 



DESCRIPTION 



34590A APACHE RUG 



1536 

1500 f 

INVOICEJ:001300925 

1C , 0 INVOICE EXPIRES:02/13/00 
1542 YOUR REFERENCE#:23456 
DESCRIPTION:EBAY AUCTION 44587956 

QUANTITY PRICE SUBTOTAL " — DATE CREATED ,STATUS_J 



1 



$300.00 



$300.00 02/18/00 



EXIT SECURE AREA 



1546 



ISTATUS KEY 



i 



P=PA1D 
W=WAITING ON BUYER 
D=DECLINED BY BUYER 
E=EXPIRED 



INSURANCE 



20.00 



SHIPPING & HANDLING 



90.00 



TOTAL TO.. 
CHARGED TO BUYER 
SERVICE FEE 
CHARGED TO YOUR 

ACCOUNT: 

TOTAL PAYMENT FOR 



0.00 



$410.00 



-10.00 



SELLER: $400.000r~t 1 540 



1544 



1538 



«BACK INVOICE NEXT» 



lMlK ^^ QccepD ^ 



1550 



INTERNET ZONE 



li DCAffElLA 1HK II CXEARHIiG SPAlfPAMaiCAO IdEXPLORWGI taUiCROSOFTW- llDUPLOADaDATAl □ 



tft3UM 



FIG.15 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/US00/30483 



16/23 



Id AMERICAN EXRRESS-MlCROSOFT INTERNET EXPLORER 



FILE EDIT VIEW 60 FAVORITES HELP 



CO 



O O G Ql O O € ' B B A 
BACK FORWARD STOP REFRESH HOME SEARCH FAVORITES HISTORY CHANNELS FULLSCREEN MAIL PRINT 



ADDRESSjD HTTP JTRBECA.SIG.BSri.COU/CONSmiER JO. C0WSUHER/BUILDflH_2ASP 



^L«K> 



AMERICAN 
EXPRESS 



mm 



PERSONAL \° SMALL BUSINESS °C0RP0RATI0"NST 



t> CARDS 



CONSUMER TO CONSUMER PAYMENTS 
INVOICE #01300925 CANCELED 

AS YOU REQUESTED, WEHAVE CANCELED YOUR LAST INVOICE 



TRAVEL & 
ENTERTAINMENT 



FINANCIAL PLANNING & 
INVESTING 



EXPRESS SHOPPER 



1600 



ISTART A NEW TRANSACTIONS I BACK TO MAIN PAGE h > 
M602 1 



1604 



EXIT SECURE AREA 



COPYRBHTCfflXH AUERICAN EXPRESS COMPANY AIL RIGHTS RESERVED.USERS OF THE SHE AGREE TO BE BOUND FJYTHE TERliS QFTHE AMERICAN EXPRESS WEB SITE RULES AND 
REGULAT10NS.VSW WEB SITE RULES AND REGULATIONS AND TRADEUARKS AND PRIVACY STATEUENT OF AUERiCAN EXPRESS. 



INTERNET 20NE 



□STARTltaWB0X4fiCRQ 1 1 □YAHOO UAL I fDCA ^FlLATMll □IEARNM6 SPA 1 1 □ AKRJCAfL I (PEXRORJHGI iDtECfiOSOn W niDUPLOADED DATA I Q 



lOAil 



FIG.16 



SUBSTITUTE SHEET (RULE 26) 



WO 01/33522 



PCT/US00/30483 



17/23 



PURCHASER TRANSACTION CONFIRMATION 



([start) 



PURCHASER RECEIVES EMAIL RE: TRANSACTION INVOICE 

I 



PURCHASER FOLLOWS LINK TO PURCHASER TRANSACTION 
REVIEW PAGE 



1702 
1704 



r- 



PURCHASER 
COMPLETES & 
SUBMITS 

PURCHASER 
TRANSACTION 
REVIEW PAGE 



1706 



PURCHASER LOGIN & 
CARD SfLECTED 



PURCHASER 
REGISTERS; 



T 



1732 



PURCHASER 

DECLINE 
TRANSACTION 
PAGE 



DECLINE 



1714 




PURCHASER LOGIN & 
D DA SELECTED 



1708 



1710 



1712 



1718 



CANCEL 
TRANSACTION 

& NOTIFY 
PURCHASER* 

SELLER 



DEBIT PURCHASER'S ACCOUNT & CREDIT ESCROW 
ACCOUNT 



DISPUTE RESOLUTION 
AND/OR 
TRANSACTION REVERSAL 




1720 



I. 



DISBURSE 
FUNDS TO 
SELLER 



FIG. 17 



NOTIFY 
^PURCHASER 
AND SELLER 



1726 



1728 



SUBSTITUTE SHEET (RULE 26) 



WO 01733522 



PCT/US00/3O483 



18/23 



A MERICAN EXPRESS-MICROSOFT INTERNET EXpCoW 
IT VIEW GO FAVORITES BELP~ 



O a g Ql a o ^9 E3 <a 
BACK FORWARD STOP REFRESH HOME SEARCH FAVORITES HISTORY CHANNELS FULLSCREEN HAH 



QJ 



ADDRES5jgrinF-JTRIBECA.SIGJSH.C0MA;0NSyHER_TO_C0NSU>IERJBUILD<IH_2ASP 



MLINK> 



AMERICAN 
EXPRESS 



mm 



PERSONAL \° SMALL BUSINESS QCORPORATIONSr 



1800 



TRAVEL 4 
ENTERTAINMENT 



FINANCIAL PLANNING & 
INVESTING 



CONSUMER TO CONSUMER PAYMENTS 
VIEW INVOICES 



ISTEP41-REVIEW INVOICE 1 


TO: 6L0RIAPUBLIG@YAH0O.-C0M 
FROM: JOHN_SAMPLE@H0TUAIL.C0U 


INVOICES:001300925 
INVOICE EXPIRES:02/13/00 
YOUR REFERENCES:23456 
DESCRIPTION:EBAY AUCTION 44587956 


1 DESCRIPTION QUANTITY 




PRICE SUBTOTAL 1 


34590A APACHE 1 
RUG 




$300.00 $300.00 
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TO: GL0RIAPUBLIC@YAH00.COM 
FROM: J0HN.SAMPLEiH0TMAIL.COM 



1NVOICE#:001300925 
INVOICE EXPIRES:02/13/00 
YOUR REFERENCEI.23456 
OESCRIPTION:EBAY AUCTION 44587956 



34590A 
RUG 



APACHE 



Mllii 



I ll'l — HI llilMl 



1 



$300.00 



$300.00 



INSURANCE 


20.00 


SHIPPING (HANDLING 


90.00 


OTHER 0.00 


TOTAL TO BE 


$410.00 


CHARGED TO BUYER 



CARD INFORMATION 

NAME AS IT APPEARS ON THE CARD 

GLORIA Q. PUBLIC 

CARD ACCOUNTS 
XXXX-XXXX-XXXX 

BASIC CARDMEMBER-S BIRTH DATE 
01/02/1967 

BILLING ADDRESS 



CARD IDENTIFICATION! 
4432 

EXPIRATION DATE 
XX/XXXX 



I AGREE TO THE TERMS 
4 CONDITIONS SET BY 
THE SELLER AND TO PAY 
THE TOTAL CHARGES ON 
THIS INVOICE. 
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(300.00 



$300.00 







INSURANCE 


20.00 






SHIPPING & HANDLING 


90.00 






OTHER 


0.00 


■JSdr 




TOTAL 


$410.00 



CARD INFORMATION CARD IDENTIFICATION : 

NAME AS IT APPEARS ON THE CARD 4432 
GLORIA Q. PUBLIC EXPIRATION DATE 

XX/XXXX 

CARD ACCOUNT! 
XXXX-XXXX-XXXX 

BASIC CARDMEMBER'S BIRTH DATE 
01/02/1967 

BILLING ADDRESS 

327 JOHNSON COURTAPT.3 

CHICAGO.IL 

02753 

SELLER WILL NOT SEE YOUR ACCOUNT INFORMATION. 



I AGREE TO THE TERMS 
& CONDITIONS SET BY 
THE SELLER AND TO PAY 
THE TOTAL CHARGES ON 
THIS INVOICE. 



1904 



I DO NOT WISH TO 
PROCEED WITH THIS 



1902 



DECLINEI 



ALL SHIPPING, HANDLING & INSURANCE ARRANGEMENTS SHOULD BE MADE PRIOR TO SUBMITTING 
YOUR CARD INFORMATION. 
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INVOICE #01300925 DECLINED 

YOU HAVE INDICATED THAT YOU DO NOT WISH TO COMPLETE PAYMENT OF INVOICE #01300925. WE 

HAVE NOTIFIED MRSELLER@H0TMAIL. COM OF YOUR DECISION. 
IF YOU STILL WISH TO PROCEED WITH THIS TRANSACTION, PLEASE CONTACT THE SELLER DIRECTLY 

ATMRSELLER@HOTMAIL.COM. 
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